Messages in this thread | | | Date | Tue, 21 Dec 1999 16:12:40 +0100 | From | Jamie Lokier <> | Subject | Re: Thread-private mappings and graphics (was Re: Per-Processor DataPage) |
| |
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/
| |