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/