Re: Thread-private mappings and graphics (was Re: Per-Processor DataPage)

Jamie Lokier (lkd@tantalophile.demon.co.uk)
Tue, 21 Dec 1999 16:12:40 +0100


James Simmons wrote:
> > Userland writes to a memory buffer, not to the hardware. Eventually the
> > program asks the kernel to flush the buffer, and the kernel complies [...]
> >
> > If the userland program waits for a long time, the hardware isn't locked
> > so there is no problem.
>
> It is better to allow that _as an option_. Of course you have to
> allow explicit flushes. But you also need to have implicit flushing for
> the sake of performance. The nice thing about the page fault method is

Why? I think it would be much better to have user space check the
watermarks and flush the buffer as it reaches each water mark. Or at
its option, some other policy. (Timer signals, optimal icache points
between major rendering units, that sort of thing).

I recall experiments with functional language memory allocators. They
allocated memory from a large region by simply incrementing the
address. Something they had to test was when the allocation reached the
end of the region, to trigger a garbage collection.

Two approaches were tried. One using a pages fault at the end and
trapping the SIGSEGV, the other explicitly comparing the address on each
allocation. The explicit compare won.

That was just one fault every <insert large block of memory>. You are
proposing faults much more often.

One obvious complaint about using page faults is the overhead of
updating mappings. Inter-CPU TLB flushes are particularly expensive.

OTOH, I just realised that if you use carefully crafted assembly
language in the user space writer, you can just wrap around in a buffer
without having to change any page mappings. The kernel would modify the
user space pointer register. Ugly, dubious but possible.

> The nice thing about the page fault method is
> that it allows you to tune the size and faulting behavior of the ping and
> pong buffers on the fly as needed. This is a wonderful way to get the
> most out of those fifo watermark interrupts I mentioned before. If the
> high watermark IRQ fires, your driver code is pushing the hardware fifo
> too hard. Usually that means that userspace code is pushing the driver
> too hard, so you can throttle back the userspace command buffer filling
> code by faulting more often and then raise the ping/pong buffer size so
> faults occur less often. If the low watermark IRQ fires, you are starving
> the hardware and should fault more often unless scheduling priorities
> prevent this or your buffer size == PAGE_SIZE.

I don't see why user space cannot handle this watermarking itself, but
you may be right.

-- Jamie

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/