cvs commit: src/sys/kern kern_poll.c
rwatson at FreeBSD.org
Tue Sep 6 03:33:18 PDT 2005
On Tue, 6 Sep 2005, Luigi Rizzo wrote:
> On Tue, Sep 06, 2005 at 10:18:28AM +0400, Gleb Smirnoff wrote:
>> 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
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
More information about the cvs-src