Date: Mon, 19 Jun 2000 18:14:15 -0500 From: Jonathan Lemon <jlemon@flugsvamp.com> To: David Greenman <dg@root.com> Cc: Jonathan Lemon <jlemon@flugsvamp.com>, Mike Smith <msmith@FreeBSD.ORG>, arch@FreeBSD.ORG Subject: Re: kblob discussion. Message-ID: <20000619181415.K37084@prism.flugsvamp.com> In-Reply-To: <200006192251.PAA18923@implode.root.com> References: <20000619172041.G37084@prism.flugsvamp.com> <200006192251.PAA18923@implode.root.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, Jun 19, 2000 at 03:51:58PM -0700, David Greenman wrote: > >> > Also, if I want to send data from disk -> network, with the kblob > >> > API, I essentially have the following sequence of calls: > >> > > >> > read(fd, address, length) > >> > kblob(address, length) > >> > kblobsend(...) > >> > > >> > which is to say, the data is copied from > >> > disk -> userspace (assuming direct I/O) > >> > userspace -> kernel, > >> > kernel -> network. > >> > > >> > Why shouldn't I be able to bypass second copy entirely and do: > >> > disk -> kernel (data now in kernel 'blob') > >> > kernel -> network > >> > >> Because this isn't what you use kblob for. That's what you use sendfile > >> for. > > > >But sendfile doesn't leave the data cached in kernel space for reuse, > >so it isn't suitable for this. > > I think you need to review the code a bit more closely. sendfile() > definately leaves the pages cached, and definately uses any cached pages > that it finds, thus avoiding I/O when possible. Um, even in the case for "direct I/O" above? Note that I'm not actually using a filesystem at all, just raw devices. I didn't think that the vm system caches this data, but I don't claim extensive knowlege about the vm subsystem. -- Jonathan To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20000619181415.K37084>