From mboxrd@z Thu Jan 1 00:00:00 1970 From: George Dunlap Subject: Re: [PATCH 3/7] xen: sched: better handle (not) inserting idle vCPUs in runqueues Date: Thu, 8 Oct 2015 16:27:12 +0100 Message-ID: <56168B50.6010800@citrix.com> References: <20151008124027.12522.42552.stgit@Solace.station> <20151008125251.12522.3916.stgit@Solace.station> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZkD6C-0007hT-J5 for xen-devel@lists.xenproject.org; Thu, 08 Oct 2015 15:27:16 +0000 In-Reply-To: <20151008125251.12522.3916.stgit@Solace.station> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Dario Faggioli , xen-devel@lists.xenproject.org Cc: George Dunlap , Juergen Gross List-Id: xen-devel@lists.xenproject.org On 08/10/15 13:52, Dario Faggioli wrote: > Idle vCPUs should never really be explicitly inserted > in any of the schedulers' runqueue. In fact, they are > just put in execution immediately (either on boot, or > when a pCPU is assigned to a cpupool), and it will be > the first scheduling decision that --by preempting > them-- will 'park' them in the queue. > > In fact, avoiding inserting those vCPUs in runqueues > is something that Credit2 and RTDS intercept and > forbid already (when implementing insert_vcpu()). > Credit1 does that implicitly, as the idle vCPU will > always be already running when insert_vcpu() is called, > and hence not put in the runqueue. > > Let's make it *always* explicit, as that simplifies > things by quite a bit. For instance, we can now > introduce some BUG_ON() guards, with the twofold > objective of making this assumption clear, and of > catching misuse and bugs. > > The check for whether we'd be inserting an idle vCPU > in a queue, now, happens, once and for all schedulers, > in generic code, at vCPU initialization time, while > we can just avoid trying (and always failing!) doing > so when doing cpupools manipulations. > > Signed-off-by: Dario Faggioli Although it might be easier to evaluate the previous patch if this one were moved behind it in the series: Acked-by: George Dunlap -George