Communications kernel -> userland
adam at migus.org
Tue Jul 22 10:43:37 PDT 2003
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
>> 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:
> 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
> Robert N M Watson FreeBSD Core Team,
> TrustedBSD Projects
> robert at fledge.watson.org Network Associates
> freebsd-hackers at freebsd.org mailing list
> To unsubscribe, send any mail to
> "freebsd-hackers-unsubscribe at 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)
More information about the freebsd-hackers