Date: Sun, 8 Mar 1998 08:38:38 -0700 (MST) From: Marc Slemko <marcs@znep.com> To: Julian Elischer <julian@whistle.com> Cc: hackers@FreeBSD.ORG Subject: Re: kernel wishlist for web server performance Message-ID: <Pine.BSF.3.95.980308083137.2799W-100000@alive.znep.com> In-Reply-To: <Pine.BSF.3.95.980307231219.16777G-100000@current1.whistle.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sat, 7 Mar 1998, Julian Elischer wrote: > > > > Let me put it this way: how else do you propose to do copy avoidance to > > avoid an extra copy going into the mbufs? The data must go from the > > buffer cache to the network without any copy other than to the network > > card itself. Why is your other method of doing this any less of a hack? > [...] > I would like to add here that in FreeBSD's unified VM/Buffer cache, > a mmapped file IS the buffer cache > so that a send() from an mmapped file IS copying direct fromt he buffer > cache. Ther eis ONE copy.. that from the buffer cache, into the mbuf. But the point is that you still have to copy it into the mbuf, you still have to use the memory for the mbuf, etc. This uses more CPU and memory bandwidth, increases memory use, and means you may have to chop things up smaller to avoid using too much memory for mbufs. To avoid that copy, you have two choices. First, you can play around with copy avoidance for mmap() then send() or write(). This can be done with COW, or page flipping. See the HP paper for more details on this approach. Doing it this way is really an ugly hack and there are numerous difficulties that crop up, making it less than desirable. Or, you can use sendfile() and code it so it doesn't have to copy into mbufs. This is easier because of where the data is coming from. Now, doing this right is dependent on having the right networking hardware and networking drivers. It is, however, a very worthwhile feature from a performance standpoint and more and more other OSes are adding it. > > (assuming that the data got into the memory via DMA in the first place..) > you may need to have a subprocess go through and tuch all the pages to > get them into ram first.. > > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.3.95.980308083137.2799W-100000>