Call for performance evaluation: net.isr.direct (fwd)

[Bruce Evans]

On Sat, 15 Oct 2005, Robert Watson wrote:

> On Sat, 15 Oct 2005, Bruce Evans wrote:
>> ...  However, for netisrs I think it is 
>> common to process only 1 packet per context switch, at least in the 
>> loopback case.
>
> The Mach scheduler allows deferred wakeups to be issued -- "wake up a thread 
> in the sleep queue -- but when it's convenient" to avoid premature preemtion. 
> This helps avoid immediate preemption where it's unnecessary and/or 
> undesirable: specifically, to avoid preemption when the preempting thread 
> will immediately require a lock held by the signalling thread, as occurs with 
> the netisr and TCP.

Hmm, does it still do that?  A year or two, at least the loopback case used
to run into itself on Giant, and pushing down giant made things worse
(scheduling the netisr would switch immediately because the netisr was
"MPSAFE" but then the netisr would immediately block on Giant and switch
back, so it took 2 expensive context switches instead of just 1 to get a
netisr to do anything).

> I've not yet investigated tweaking things, or even a 
> scheduler trace to see for sure that this is happening, but it wouldn't 
> surprise me at all if we're seeing extra context switches due to premature or 
> untimely preemption following wakeup.

Probably the problem is largest for latency, especially in benchmarks.
Latency benchmarks probably have to start cold, so they have no chance
of queue lengths > 1, so there must be a context switch per packet and
may be 2.

Bruce