From owner-cvs-src@FreeBSD.ORG Tue Sep 6 10:33:18 2005 Return-Path: X-Original-To: cvs-src@FreeBSD.org Delivered-To: cvs-src@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 25A1E16A41F; Tue, 6 Sep 2005 10:33:18 +0000 (GMT) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [204.156.12.53]) by mx1.FreeBSD.org (Postfix) with ESMTP id BF92343D46; Tue, 6 Sep 2005 10:33:17 +0000 (GMT) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by cyrus.watson.org (Postfix) with ESMTP id 65D1D46B08; Tue, 6 Sep 2005 06:33:16 -0400 (EDT) Date: Tue, 6 Sep 2005 11:33:16 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Luigi Rizzo In-Reply-To: <20050906012755.B34182@xorpc.icir.org> Message-ID: <20050906112608.N51625@fledge.watson.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> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: cvs-src@FreeBSD.org, Gleb Smirnoff , cvs-all@FreeBSD.org, src-committers@FreeBSD.org Subject: Re: cvs commit: src/sys/kern kern_poll.c X-BeenThere: cvs-src@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: CVS commit messages for the src tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Sep 2005 10:33:18 -0000 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