Subject: Re: Interrupt, interrupt threads, continuations, and kernel lwps
To: Bill Studenmund <email@example.com>
From: None <firstname.lastname@example.org>
Date: 02/22/2007 16:49:40
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