Pushing image transport logic down the stack

[Alan Cox]

Ar Llu, 2006-09-04 am 16:32 -0700, ysgrifennodd Keith Packard:
> One question here is how to notify the application that the data have
> been read by the graphics card. A possibility not yet addressed is to
> invalidate the PTEs for the data and block the process when it tries to
> write additional data there, or perhaps even allocate new pages in place

Dear gods no, please don't go that way. TLB shootdown is expensive and
does not scale in a pretty way. Far better simply to have a flag
attached to the pages which the kernel can atomic operate on (or use a
futex for that matter).

> Providing some way to pass chunks of address space from application to
> server without needing to pre-define them seems important here; it would
> be nice to just hand the hardware a pointer to the image buffer and have
> it able to access it directly. What kinds of kernel APIs would we need
> for this, and what kinds of hardware changes would be required to make
> that performant?

The killer is the without pre-planning side of it. If you used posix
shared memory objects and allocated those sanely instead of passing
arbitary address space it would all be there already I think.

> I'm interested in learning how we could create a shared object that
> referred to existing address space. We already do that from user space
> to kernel; why not between two processes?

Creating a new shared object is easy, although anonymous shared memory
objects are a bit more complicated (minor understatement) if you want
them pageable as we would. Trying to share an existing object gets very
very horrible very fast because of things like copy on write, file
permission models and ugly ugly stuff like device mappings. We have
rules about mmap()ing /proc/self/mem and /proc/pid/mem for reasons

You'd need to pin down a good kernel hacker who knows mm/vm for that
well. I certainly couldn't do it 8)

Alan