Re: Thread-private mappings and graphics (was Re: Per-Processor Data

David S. Miller (davem@redhat.com)
Thu, 16 Dec 1999 16:29:10 -0800


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/