In message <20070222174642.GB24922@netbsd.org>, Bill Studenmund writes:

[...]

>I think the problem is you've assumed an implementation, and specifically
>you've assumed one other than what Andy was suggesting.

I came to that conclusion after re-reading Andrew's reply.  i think
the problem is terminology.  I'm not used to seeing taking an
interrupt called a "context switch" instead of, well, taking an
interrupt or a trap.


>My understanding is that Andy has figured out a way to have, at least on
>x86, the interrupt handler borrow the context of the interrupted thread.
>So the interrupt context switch is also the context switch to the thread.
>
>That's why he said it was the same as what we do now.

That's an unfortunate choice of terminology. it'S inviting confusion
to say that a new approach does just what we did before, when it
doesn't, and the details matter.


>Let's try it and see! Rather than discuss hypotheticals, let's get #s.
>Either the numbers will show little change, which will make ALL of us
>happy, or the numbers will show a marked decrease, which will displease
>ALL of us. :-)

Numbers would be interesting.  But what kind of numbers?  Single-CPU?
Multi-CPU?  Or CPUs with (gack) virtually-indexed caches and TLBs
without address-space-IDs?  I don't see how Andrew's scheme would
really work there, but maybe I'm missing something.

The other issue I see is that Andrew is assuming that blocking (in his
sense, meaning doing the full work of the deferred context switch) is
a rare case.  I don't buy that, not for networking.  Look at the
resources put into making FreeBSD a fine-grained kernel, and notice
that FreeBSD-6 still has one big lock around the network stack and
socket-layer code.