Messages in this thread | | | Date | Tue, 14 Dec 1999 00:08:01 -0800 | From | "David S. Miller" <> | Subject | Re: Thread-private mappings and graphics (was Re: Per-Processor Data |
| |
Date: Mon, 13 Dec 1999 23:54:15 -0800 From: Jon Leech <ljp@oddhack.engr.sgi.com>
This doesn't address the problem. First, the threads need to refer to *different* graphics contexts. Second, the API requires that these contexts be identified by some thread-specific mechanism available to the graphics library, not by explicit stack pointers in the application - whether that mechanism is private mappings or tarot cards matters not, so long as it's extremely fast.
So fork()'d processes store the graphics library shared state in a shared/writable mapping area.
What you proposed is: threads + thread local mappings Linus is suggesting instead: processes + shared mappings
The latter provides what you'd like to do without any of the overhead or complexity assosicated with the former. And I think that alone will make up for whatever performance advantages are obtained by the former.
As someone who intern'd at SGI for a few months and also saw how the aforementioned IRIX mechanism works, I can definitely say this is something we never want in Linux. TLB miss trap handler changing based upon if the thread has thread-local mappings, all the special cases in vfault/pfault to find the correct page tables to lookup, no thanks.
Later, David S. Miller davem@redhat.com
- 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/
| |