Date: Tue, 20 Jun 2000 09:35:26 -0700 From: Alfred Perlstein <bright@wintelcom.net> To: Dag-Erling Smorgrav <des@flood.ping.uio.no> Cc: arch@FreeBSD.ORG, jlemon@FreeBSD.ORG, msmith@FreeBSD.ORG, nate@FreeBSD.ORG Subject: MORE: Re: kblob discussion. Message-ID: <20000620093526.Q17420@fw.wintelcom.net> In-Reply-To: <xzpk8fktu2x.fsf@flood.ping.uio.no>; from des@flood.ping.uio.no on Tue, Jun 20, 2000 at 02:28:38PM %2B0200 References: <20000619111309.E26801@fw.wintelcom.net> <xzpk8fktu2x.fsf@flood.ping.uio.no>
next in thread | previous in thread | raw e-mail | index | archive | help
* Dag-Erling Smorgrav <des@flood.ping.uio.no> [000620 05:28] wrote: > Alfred Perlstein <bright@wintelcom.net> writes: > > oops, you can find the preliminary kblob diffs over here: > > > > http://people.freebsd.org/~alfred/kblob/kblob-final.diff > > > > It's a new syscall, less overhead than sendfile and useful for > > serving small chunks of data very quickly. > > Do kblobs do anything that can't be easily done with sendfile() by > mmapping suitably large chunks of /dev/null? Sendfile's vm tricks and additional overhead per-page sized chunks make it unsuitable for sending smaller chunks of data. Paul Saab noticed that for some workloads it was actually slower than just copying the data while working at Hotmail. Kblob would have given FreeBSD the edge to stomp win2k without actually putting the webserver in the kernel. Last night I started thinking about making kblob more flexible, here's the problem I came across: All the papers that have been given to me make sure that once a 0 copy buffer is shared across subsystems it is immutable until the data it's loaned has gone back to no references except by the user process. Not following the above system is _wrong_. There's the problem, it's entirely possible that a connection that has had a an mbuf referencing a kblob has been shut down improperly forcing the kblob to be held for much longer than needed. If we do have an API that allows for modifying kblobs once they are constituted it can only be done when no other systems are referencing the data. This becomes a tracking nightmare if we want to allow the user program to figure out exactly which socket they have open is causing a kblob to stay "stuck". My intention is to leave this up to the system, one can set a kblob non-blocking to return EAGAIN if it's in use, or block on it until the refcount goes back to one? Perhaps we can attach kevents to them to notify the user when they are "free" again. Now it seems that it's not as lightweight anymore. *sigh* -- -Alfred Perlstein - [bright@wintelcom.net|alfred@freebsd.org] "I have the heart of a child; I keep it in a jar on my desk." 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?20000620093526.Q17420>