Date: Tue, 22 Jul 2003 13:43:31 -0400 (EDT) From: "Adam Migus" <adam@migus.org> To: "Robert Watson" <rwatson@freebsd.org> Cc: freebsd-hackers@freebsd.org Subject: Re: Communications kernel -> userland Message-ID: <63051.204.254.155.100.1058895811.squirrel@mail.migus.org> In-Reply-To: <Pine.NEB.3.96L.1030721171319.99228D-100000@fledge.watson.org> References: <20030721190146.GB43543@garage.freebsd.pl> <Pine.NEB.3.96L.1030721171319.99228D-100000@fledge.watson.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Robert Watson said: > > On Mon, 21 Jul 2003, Pawel Jakub Dawidek wrote: > >> For example syscall is marking some range with mark() >> function. For now >> on this range isn't accessable from userland. If >> process will try to >> write to this page, page is copied (copy-on-write). >> If this page will >> be modified by kernel it will be marked as MODIFIED. >> Now when syscall >> will call unmark() on this range we could get two >> scenarious: >> >> 1. Page is marked as MODIFIED (by kernel) so >> userland copy >> of this page (if it exists of course) is >> destroyed and >> this page will be putted in its place. >> This is replacement for copyin() and then >> copyout() or >> just copyout().. >> 2. Page isn't marked as MODIFIED, so kernel version >> of page >> is destroyed (is there is userland version). >> This is replacement for just copyin(). >> >> There could be other ways. Thread/process could be >> locked if it is >> trying to access memory marked with mark() function. >> And this, I think, >> don't hit performance, because this happends really >> rarely. So maybe it >> is better to lock thread for a moment instead of >> doplicating page, but I >> don't think so. > > This sounds a bit like some of the IO Lite stuff -- > moving to a > page-centric model for IO interfaces to avoid copy > operations, in many > cases able to share pages between applications, buffer > cache, network > buffers, etc. Take a look at: > > http://www.cs.princeton.edu/~vivek/ > > For some details. Some of the benefits of this > approach are captured in > the common case through sendfile(), in practice, but > it's definitely worth > a read. > > I guess what I had in mind was something more > network-specific, with > interfaces optimized for memory mapped network packet > streams. In the > simplest case, something like memory-mapping the BPF > buffer from kernel > space to userspace, with some sort of simple stream > synchronization so > that the user application could notify the kernel as to > when it could > reuse bits of the buffer, but avoiding copy operations > and lots of context > switching. > > Robert N M Watson FreeBSD Core Team, > TrustedBSD Projects > robert@fledge.watson.org Network Associates > Laboratories > > > _______________________________________________ > 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" > Perhaps I'm not understanding you right but I think Pawel's idea is cool. It seems to fulfill your requirements (except being network specific). I suppose if it were network specific we could optimize it for packet streams and if we made it complicated enough it would require quite an elaborate sychronization and notification mechanism. Is that closer to what have in mind? -- Adam Migus - Research Scientist Network Associates Laboratories (http://www.nailabs.com)
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?63051.204.254.155.100.1058895811.squirrel>