Date: Tue, 6 Sep 2005 11:33:16 +0100 (BST) From: Robert Watson <rwatson@FreeBSD.org> To: Luigi Rizzo <rizzo@icir.org> Cc: cvs-src@FreeBSD.org, Gleb Smirnoff <glebius@FreeBSD.org>, cvs-all@FreeBSD.org, src-committers@FreeBSD.org Subject: Re: cvs commit: src/sys/kern kern_poll.c Message-ID: <20050906112608.N51625@fledge.watson.org> In-Reply-To: <20050906012755.B34182@xorpc.icir.org> References: <200509051602.j85G2Bpo090258@repoman.freebsd.org> <20050905094341.A23343@xorpc.icir.org> <20050905180050.GB41863@cell.sick.ru> <20050905141451.A27290@xorpc.icir.org> <20050906061828.GQ41863@cell.sick.ru> <20050906012755.B34182@xorpc.icir.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20050906112608.N51625>