From owner-freebsd-hackers@FreeBSD.ORG  Mon Dec 12 08:42:25 2005
Return-Path: <owner-freebsd-hackers@FreeBSD.ORG>
X-Original-To: freebsd-hackers@freebsd.org
Delivered-To: freebsd-hackers@freebsd.org
Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125])
	by hub.freebsd.org (Postfix) with ESMTP id 6F1C416A41F
	for <freebsd-hackers@freebsd.org>; Mon, 12 Dec 2005 08:42:25 +0000 (GMT)
	(envelope-from ced@grumly.eu.org)
Received: from spike.grumly.eu.org (spike.grumly.eu.org [195.5.253.226])
	by mx1.FreeBSD.org (Postfix) with ESMTP id DC05143D70
	for <freebsd-hackers@freebsd.org>; Mon, 12 Dec 2005 08:42:19 +0000 (GMT)
	(envelope-from ced@grumly.eu.org)
Received: by spike.grumly.eu.org (Postfix, from userid 1001)
	id A0DFA11593; Mon, 12 Dec 2005 09:39:30 +0100 (CET)
Date: Mon, 12 Dec 2005 09:39:30 +0100
From: Cedric Tabary <ced@grumly.eu.org>
To: freebsd-hackers@freebsd.org
Message-ID: <20051212083930.GC91837@efrei.fr>
Mime-Version: 1.0
Content-Type: text/plain; charset=iso-8859-15
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
Subject: mmap() sendfile()
X-BeenThere: freebsd-hackers@freebsd.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Technical Discussions relating to FreeBSD
	<freebsd-hackers.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-hackers>, 
	<mailto:freebsd-hackers-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-hackers>
List-Post: <mailto:freebsd-hackers@freebsd.org>
List-Help: <mailto:freebsd-hackers-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-hackers>,
	<mailto:freebsd-hackers-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Mon, 12 Dec 2005 08:42:25 -0000

I was looking at the freebsd port of thttpd and i saw this patch :
/usr/ports/www/thttpd/files/patch-mmc.c

This is some sort of file cache, it works by mmap()ing some files and
keeping the mmap address in a hashtable. I suppose this is used to keep
the file in memory until munmap() is called.

The patch is just removing the mmap() and keeping file descriptors open
for use by sendfile(). But I don't know if replacing the mmap() by
sendfile() has the same cache effect ?!
Keeping the file descriptor open after using sendfile() will keep the
file in memory ??

If it is true, doing a sendfile() on some very big files (even if not
keeping the descriptor open after) will kill the cache ?

Please help me to understand why this patch ? and the difference between
sendfile() and mmap() at the memory or cache level..

Cédric