From owner-freebsd-arch Mon Jun 19 16: 2: 1 2000 Delivered-To: freebsd-arch@freebsd.org Received: from implode.root.com (root.com [209.102.106.178]) by hub.freebsd.org (Postfix) with ESMTP id C8FF037B7BE; Mon, 19 Jun 2000 16:01:54 -0700 (PDT) (envelope-from dg@implode.root.com) Received: from implode.root.com (localhost [127.0.0.1]) by implode.root.com (8.8.8/8.8.5) with ESMTP id PAA18923; Mon, 19 Jun 2000 15:51:58 -0700 (PDT) Message-Id: <200006192251.PAA18923@implode.root.com> To: Jonathan Lemon Cc: Mike Smith , arch@FreeBSD.ORG Subject: Re: kblob discussion. In-reply-to: Your message of "Mon, 19 Jun 2000 17:20:41 CDT." <20000619172041.G37084@prism.flugsvamp.com> From: David Greenman Reply-To: dg@root.com Date: Mon, 19 Jun 2000 15:51:58 -0700 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG >> > 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. -DG David Greenman Co-founder, The FreeBSD Project - http://www.freebsd.org Manufacturer of high-performance Internet servers - http://www.terasolutions.com Pave the road of life with opportunities. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message