Messages in this thread | | | Date | Thu, 16 Dec 1999 16:40:09 -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: > 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). > > And this scheme has some kind of provision that in the contention case > it knows how to go off and do some matrix multiplications instead of > spinning for the lock while another thread is pummeling triangles to > the card, right?
Right.
What happens is that it's basically a user-mode spinlock that on contention does a kernel ioctl.
The spinlock is in a shared memory data structure, that the kernel driver also knows about etc, and yes it needs kernel support for the final product, but you can do a lot of testing in user-mode alone (make it thread-safe within one process first, and THEN look at how to make it safe between processes through a shared area).
> Oh. And btw. It's already been done. See the 3dfx driver. > > This was the premise of most of this thread I thought. "3dfx do it > the lock way" and here is some other way we're discussion the merits > of for hardware that has the capability.
Note that historically atomic locks have been EXPENSIVE. I think that was true on MIPS too, even with the load-locked thing, just because with the weak cache coherency the thing was initially done on the _bus_, not inside the CPU. But happily that time is long gone, and it's not coming back.
(The early alpha implementation of LD_L + ST_C was entierly uncached, and just took a hundred cycles or more to generate a SMP-safe lock. Ugh. Double-ugh. Intel does it in 20 cycles or so, and I think even that is excessive, but they probably have good synchronization reasons for it).
So it may be that at one point people _really_ didn't want to do the explicit lock. I think that time is past.
Note that the 3dfx driver works, but who knows, it can certainly have bugs. But I did not get a bad feeling about including the DRM code from Precision Insight into the kernel - unlike this "playing with mappings" thing that just makes me shiver.
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/
| |