Subject: Re: splusb()
To: SODA Noriyuki <firstname.lastname@example.org>
From: Garrett D'Amore <email@example.com>
Date: 05/04/2006 10:27:04
SODA Noriyuki wrote:
>>>>>>On Thu, 4 May 2006 11:51:05 +0200,
> Hans Petter Selasky <firstname.lastname@example.org> said:
>>How about using mutexes, like on FreeBSD, instead of splxxx?
>FreeBSD (and Solaris)'s way makes kernel synchronization somewhat
>simpler, but it has certain drawbacks, e.g. it makes interrupt
>processing definitely slower.
>Also, I don't think using mutex helps this particular case much.
I don't know about FreeBSD much, but the Solaris mechanism is well
designed to support real SMP and properly has things like
priority-inheritence to avoid priority inversion. They are harder to
use in drivers than splxxx(), because there is slightly more setup and
tear down (each driver has its own mutexes, etc.)
The splxxx stuff is single processor legacy from the idea that you could
just set the processor mask and that this was sufficient.
If we want to support true kernel SMP ever, then we need to go to
mutexes or something like them.
As far as performance goes, mutexes are not likely to be very different
if design so that on uni processor platforms acquiring a mutex that has
an "interrupt cookie" set for it (i.e. a mutex that protects data
accessed in an ISR) degenerates into just doing the splxxx thing
internally. It should be possible (though less elegant) to make this
even evaluate to splxxx() on those platforms without even an extra
function call. (Though you do have to add a branch test to determine
whether to splxxx, and if so, at what level.)
Properly designed mutexes on SMP platforms cost more, due to
mulitprocessor synchronization and the fact that drivers will tend to
have a lot more calls to lock/unlock for fine-grained locking (to get
better performance) than they typically do with just splxxx today.