I don't understand why people are so hung up about page faults.
I think it's ENTIRELY because of historical baggage, and the particular
implementation under Irix.
What I'm surprised about is that nobody seems to just come out and say:
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.
Ok. Nobody else said it, so now I have.
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. The whole
thing is also extremely hard to debug, and implies a much tighter coupling
between the kernel and the X server than there should ever be!
You can do a _regular_ SMP-safe lock with _real_ thread safety and no
faulting behaviour in a few instructions. We're talking maybe 50 cycles
here - about 40 cycles for the actual two locked instructions, and a very
generous 10 cycles to check whether you are the old owner and going to the
switch routine if not).
Note that IF you have to switch contexts, the regular lock will be a hell
of a lot faster than taking page faults, so let's just ignore that case:
page faulting obviously loses, and there's no way anybody can seriously
claim anything else.
So let's look at the no contention case, where you got the lock, and
everything was fine. You spent 50 cycles on verifying it. Big deal. That's
50 _CPU_ cycles. Not memory cycles, not PCI cycles. In exchange for those
50 cycles you get;
- you can debug things
- it's thread-safe
- you have much lower latency if you DO get graphical context switching,
and you can actually test it in user space first!
Oh. And btw. It's already been done. See the 3dfx driver.
So forget this playing with mmap and page faults. Use mmap() as a way to
access the physical hardware, but NOT as a way to switch contexts. Ok?
Linus
-
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/