I don't want to enter into the debate over kernel implementation
details, but do want to bring up a use for thread-private mappings that
may not be on people's minds. Most of the discussion so far seems to be
assuming apps like web serving. Another area where multithreading is
important is 3D. The OpenGL API relies on an implicit graphics context,
so that multithreaded apps need to do some sort of thread-specific
lookup at each call.
Many GL calls can be just a few instructions long on suitable
hardware (e.g. shove parameters into a DMA buffer or FIFO), so the
lookup needs to be very fast. Brian Paul has done some preliminary
testing demonstrating a roughly 3:1 performance hit for performing
thread-specific lookup via pthread_getspecific() on an otherwise empty
call, giving some guidance as to impact in a real driver.
The fact is that many workstation apps using the OpenGL API rely on
threadsafe GL support, and slow lookups would cripple their performance.
We need to explore implementation options more, but the issue certainly
could be addressed by thread-private mappings, as is done today on IRIX
and other platforms.
Finally, note that "solutions" requiring changes to the OpenGL API,
such as passing a context pointer with each call (a suggestion that
might come from a pure kernel-centric POV) would impose enormous coding
and testing burdens on existing applications, invalidate all existing
documentation, and make writing portable code far more difficult in the
future. I doubt this would be a viable option.
Jon Leech
SGI
-
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/