Messages in this thread | | | From | akin@pobox ... | Date | Thu, 16 Dec 1999 20:21:02 -0800 | Subject | Re: Thread-private mappings and graphics (was Re: Per-Processor Data Page) |
| |
On Thu, 16 Dec 1999 15:53:56 -0800 (PST) Linus wrote: | | I don't understand why people are so hung up about page faults.
I wasn't around SGI at the time the mechanism was developed for their systems, but my understanding is that the big advantage of using the page-fault mechanism was clean interrupt and restart at the instruction level.
The goals were to provide access to the graphics hardware (a) with minimal overhead, so that throughput is as high as possible and latency is as low as possible; and (b) with maximal robustness, so that no misbehaved client can cause deadlock or starvation.
Direct access to hardware registers via memory-mapped I/O is about the best you can do for minimizing latency on modern microprocessors; it's also a pretty good solution for maximizing throughput compared to building a buffer and then DMAing it. (Fewer bus cycles overall.) But to avoid deadlock and starvation, the kernel needs to be able to revoke access to the graphics board at any time -- even if the client has written just the first word of a two-word graphics command. Furthermore, for clients that alternate compute and rendering phases, and especially on MP systems, you want to be able to revoke access to graphics without putting the client to sleep (so it can continue to compute until it's ready for the next rendering phase).
The page fault mechanism is one of the few hooks the hardware provides that allows the kernel to revoke access in this way, and later restart the client completely transparently. Thus the client can blithely pour commands and data onto the graphics board without ever having to worry about setup or cleanup for the very fine-grained operations that low latency rendering requires. And it can compute without interruption while some other client renders.
| Page faults are BAD. Playing with the page tables is EXPENSIVE. Page | faults fundamentally are NOT thread-safe, because page tables are | fundamentally shared among threads.
You've made your position crystal clear :-), and I'm not trying to argue with you about it. But since you asked, the reason so many people are willing to pay such costs is that it permits a much-greater-than-proportional improvement in performance and reliability in the system as a whole.
| YOU SHOULD NOT PLAY MM GAMES! They do not scale in SMP, they do not scale | with threads, and the costs of missing are absolutely huge.
Not sure I follow you. In SGI systems a page fault occurs only when it's necessary to revoke access to the graphics hardware, an event that happens no more than about 100 times/sec and typically *much* less often. The cost of handling the fault is generally swamped by the cost of saving and restoring the graphics hardware context, so the other concerns you mentioned normally aren't showstoppers.
Regards, Allen
- 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/
| |