Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 14 Dec 2005 19:40:39 +0200
From:      Iasen Kostov <tbyte@otel.net>
To:        Cedric Tabary <ced@grumly.eu.org>
Cc:        freebsd-hackers@freebsd.org
Subject:   Re: mmap() sendfile()
Message-ID:  <1134582039.40475.0.camel@DraGoN.OTEL.net>
In-Reply-To: <20051212172031.GC42322@efrei.fr>
References:  <20051212083930.GC91837@efrei.fr> <20051212083537.T78724@odysseus.silby.com> <20051212172031.GC42322@efrei.fr>

next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, 2005-12-12 at 18:20 +0100, Cedric Tabary wrote:
> On 12/12/2005 08:38, Mike Silbersack wrote:
> > On Mon, 12 Dec 2005, Cedric Tabary wrote:
> >=20
> > >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 betwe=
en
> > >sendfile() and mmap() at the memory or cache level..
> > >
> > >C=C3=A9dric
> >=20
> > My memory escapes me on all the details, but there were two potential=20
> > reasons not to use sendfile with 4.x that no longer apply in 5.x and=20
> > above:
> >=20
> > 1.  Sendfile used to send small files inefficiently, sending the http=20
> > headers in one packet and the data in another.  I fixed this in 5.x.
> >=20
> > 2.  Alan Cox improved the memory efficiency of sendfile greatly, it now=
=20
> > uses a single kernel buffer for all copies of the same block of the sam=
e=20
> > file, whereas the old implementation made an in-kernel copy of each blo=
ck,=20
> > making it no more memory efficient than using mbufs.
>=20
> What about using sendfile() or mmap() on NFS ?
>=20
> C=C3=A9dric
> _______________________________________________
> freebsd-hackers@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
> To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org=
"




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1134582039.40475.0.camel>