Messages in this thread | | | Date | Thu, 16 Dec 1999 15:53:56 -0800 (PST) | From | Linus Torvalds <> | Subject | Re: Thread-private mappings and graphics (was Re: Per-Processor Data Page) |
| |
On Thu, 16 Dec 1999, David S. Miller wrote: > > In one instance I know of a card that caches multiple rendering > context's state, something like up to 8, in the card. So the > kernel page fault handler would go:
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/
| |