tech-kern archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: mutexes, locks and so on...

On 11/12/10 13:56, Joerg Sonnenberger wrote:
On Thu, Nov 11, 2010 at 06:35:55PM +0100, Johnny Billquist wrote:
Hmm. Hard to argue about this. While I think it's nice if we try to
keep the kernel agnostic, the user api is not something I'm arguing
about changing. But it would be nice if we could leave it possible
to do things in different ways when it's not really the effect of a
CAS that is needed, but we'd still like to keep it in a way that
allowed the compiled code to be as nice and efficient as possible.

A CAS is pretty much the standard low-level primitive in the literature.
Either CAS or LL/SC are available in pretty much all non-ancient CPUs
and CAS can be emulated with LL/SC easily. If you really want to spend
time on reducing the overhead for VAX, implement ras(9) like behavior
for the kernel. That requires changing all trap entry points OR all trap
exit points to check if the return address is inside a special range
(e.g. a page that implements CAS and maybe a few other atomic ops) and
do a second level lookup if it is to backout to the start of the
routine. The problem with this approach is that it creates very nasty
bugs if you skip even a single instance.

Augh! And in which way would that improve things? Restarting operations, as well as checking if they should be restarted will hardly be cheaper than emulating CAS.

What I am observing is how slow NetBSD have become, which is very obvious on a platform like the VAX. Running something like Ultrix runs circles around NetBSD nowadays. And I'm trying to find where all the CPU cycles are going, and mutexes and locks are one place I've decided to focus on at the moment. Other suggestions are welcome.

And while it is true that CAS is the common, and very popular, low-level primitive in the litterature today, I fail to see the relevance. When we talk about locks, we should be talking in terms of acquiring and releasing the lock, not how it might be implemented at a lower level.


Home | Main Index | Thread Index | Old Index