Subject: Re: "fast" syscalls?
To: Chapman Flack <email@example.com>
From: Jachym Holecek <firstname.lastname@example.org>
Date: 03/17/2006 21:24:54
(Chapman Flack, 2006-03-17 20:33)
> Garrett D'Amore wrote:
> >>You may want to look at some of the audio drivers which allow you to
> >>mmap a buffer into userland. From memory they handle the
> >>userland/kernel interaction by updating the head/tail pointers in a
> >>circular queue, userland updates one pointer and the kernel updates
> >>the other... when they pointers are equal the queue is empty.
> And if you adapt the classic 1 reader 1 writer circular queue convention
> where the queue is 'full' when w+1 == r (mod size), that is, when
> exactly one slot is unused, then you're in business as long as the
> pointer updates in your architecture are indivisible (which might
> require carefully making sure the pointers do not straddle page
> boundaries but otherwise ought to be a safe assumption - at least that
> seemed to be the consensus when I asked). The only time you'll ever need
> to use a u/k interaction to synchronize is when the reader or writer
> actually starves or blocks, and if you can adjust buffer sizes and
> processing rates so that happens seldom, you could keep the cost of that
> interaction down by not needing to do it often.
Or, depending on your latency requirements, you could schedule a
callout to check for "falling edge" of the starvation/blocking condition
once you get starved/blocked.
With that in place, you only need u/k interaction on exceptional events
such as when you want to halt the kernel end of the pipe.