Messages in this thread | | | Date | Thu, 16 Dec 1999 16:29:10 -0800 | From | "David S. Miller" <> | Subject | Re: Thread-private mappings and graphics (was Re: Per-Processor Data Page) |
| |
Date: Thu, 16 Dec 1999 15:53:56 -0800 (PST) From: Linus Torvalds <torvalds@transmeta.com>
I think it's ENTIRELY because of historical baggage, and the particular implementation under Irix.
Perhaps it came from Irix due to it being the first, but it is far from the only system which does things precisely in this way. (HPUX, Solaris, just off the top of my head, do it the same way).
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?
If so, then perhaps I agree.
If not, then this is one of the things the page fault thing is trying to achieve. The kernel is one with the apriori knowledge of how to allocate cpu resources when a running task cannot obtain the resource he needs and someone else has computations to perform.
Relax, I understand fully the implications of the mm tricks as far as overhead is concerned. I'm just trying to weigh all the issues and come to a conclusion myself.
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.
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/
| |