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

[Robert Watson]

On Sat, 15 Oct 2005, Bruce Evans wrote:

> I'm not sure about that.  More the reverse.  Normal interrupts just 
> don't occur often enough for their context switch time to matter.  This 
> is most clear for disk devices.  Disk devices are relatively slow and 
> have even slower seeks, so have to talk to them in large (~64K) blocks 
> to get reasonable perfermonace and this results in not many transactions 
> (except with especially braindamaged hardware that does something like 
> interrupting for every 512-block).  Network devices have a normal packet 
> size of ~1500 bytes so they have to have interrupt moderation to reduce 
> the interrupt load, and non-braindamaged ones do.  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.  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.

Robert N M Watson