> Date: Wed, 18 Apr 2001 01:38:14 -0300 (BRST)
> From: Rik van Riel <[EMAIL PROTECTED]>
> > Hence, my philosophy is that task switching and preemption are
> > necessary evils because hardware does not perfectly accomodate
> > software.  If we must, we must... otherwise, use co-op switching as
> > the next best thing to straight run-to-completion.
> Except that for the [extremely performance critical] interrupt
> handlers the "software" is under control of the folks who write
> the OS.
> You need preemption for userspace because it's possibly "hostile"
> software, but things like the interrupt handlers and the kernel
> code are under your control ... this means you can code it to be
> as efficient as possible without impacting latency too much.

Right.  This is why I think that messing with pre-emption inside interrupt
handlers is a bad thing.  If kernel code doesn't cooperatively time-share,
then we likely have bigger problems than task switching. :-)

Hence I'm curious about replacing Giant with a token-passing mechanism.
If the token equals your CPU number, you have "Giant"... do what's needed.
Then set the token to the next CPU, and do what doesn't require "Giant".

Matt pointed out (to me off-list IIRC) that the mutex usually shouldn't
have to spin.  However, passing a token would involve changing the value
of some known memory location... that should be even faster and simpler
than a mutex.  No bus locking, no spinning...

AFAIK, there isn't any "good" support specifically for token passing.  But
memory reads and writes that don't even require the lock prefix... how
much faster and simpler can you get?

Want finer-grained control than "Giant"?  Any time you have "Giant"/token,
you can poll (and claim, if available) any more-specific mutex.  Nobody
else has G/tk, so there would be no races.

By using fine-grained co-op mutexes, there is very little that must be
done when we have G/tk, thus minimizing wait for G/tk.  Note, too, that we
run our standard scheduler when we don't yet have G/tk, so we're not even
blocking unless the CPU is totally idle... and then, the degenerate case
is spinning.



Brotsman & Dreger, Inc.
EverQuick Internet / EternalCommerce Division

Phone: (316) 794-8922


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Reply via email to