cvs commit: src/sys/kern kern_poll.c

[Robert Watson]

On Tue, 6 Sep 2005, Luigi Rizzo wrote:

> On Tue, Sep 06, 2005 at 10:18:28AM +0400, Gleb Smirnoff wrote:
>>   Luigi,
> ...
>> The idlepoll thread is single.
>
> ok this is very good. Re. netisr vs idlepoll, perhaps a way could be to 
> bump the idlepoll priority very high upon a net soft interrupt, and drop 
> it down to its normal value once done with the netisr cycle. so we don't 
> have to arbitrate among the two.

I think what you sort of want is for the polling thread to alternate 
between two priorities: ithread priority, and idle priority.  You want to 
bump it's priority from hardclock based on the desired scheduling 
properties of the polling configuration, and then you want to have the 
workloop in the polling thread depress its priority to idle once it's done 
sufficient work to meet minimum scheduling requirements.  That will help 
balance the competing goals of running regularly at high priority and also 
"when CPU is available".

Something to discuss is the role of direct dispatch and netisr hand-off: 
there are some nice potential parallelism benefits to handing off higher 
stack processing, such as TCP, to the netisr.  However, we could also 
direct dispatch the entire stack from within the polling thread, which 
would give us more control over CPU consumption and scheduling "by 
source".  And in the event we had multiple polling threads, with sources 
bound to particular threads, this would give us network layer parallelism 
by source.

I'm not convinced that in the eventual New World Order, we want to do 
actual polling from the netisr -- among other things, that confines 
operation to a single thread, and potentially adversely impacts the 
scheduling of non-polled network traffic (i.e., loopback traffic).

Also, if we gradually move to a polling model that handles polling for 
non-network devices, it would result in a rather mixed model.  One of the 
challenges of moving to a mixed polling model (one that supports 
non-network devices) is that network devices have a fairly well understood 
currency for work: processing of packets.  Other devices may have less 
well understood, or at least not easily comparable, workloads...

Robert N M Watson