From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754572AbcEWPmY (ORCPT ); Mon, 23 May 2016 11:42:24 -0400 Received: from mx2.suse.de ([195.135.220.15]:46635 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752863AbcEWPmX (ORCPT ); Mon, 23 May 2016 11:42:23 -0400 Message-ID: <1464018140.3618.8.camel@suse.de> Subject: Re: [PATCH 03/16] sched/fair: Disregard idle task wakee_flips in wake_wide From: Mike Galbraith To: Morten Rasmussen Cc: peterz@infradead.org, mingo@redhat.com, dietmar.eggemann@arm.com, yuyang.du@intel.com, vincent.guittot@linaro.org, linux-kernel@vger.kernel.org Date: Mon, 23 May 2016 17:42:20 +0200 In-Reply-To: <20160523141035.GC27946@e105550-lin.cambridge.arm.com> References: <1464001138-25063-1-git-send-email-morten.rasmussen@arm.com> <1464001138-25063-4-git-send-email-morten.rasmussen@arm.com> <1464001927.4537.118.camel@suse.de> <20160523120010.GB27946@e105550-lin.cambridge.arm.com> <1464008446.4537.130.camel@suse.de> <20160523141035.GC27946@e105550-lin.cambridge.arm.com> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.16.5 Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, 2016-05-23 at 15:10 +0100, Morten Rasmussen wrote: > On Mon, May 23, 2016 at 03:00:46PM +0200, Mike Galbraith wrote: > > On Mon, 2016-05-23 at 13:00 +0100, Morten Rasmussen wrote: > > > > > The problem then seems to be distinguishing truly idle and busy doing > > > interrupts. The issue that I observe is that wake_wide() likes pushing > > > tasks around in lightly scenarios which isn't desirable for power > > > management. Selecting the same cpu again may potentially let others > > > reach deeper C-state. > > > > > > With that in mind I will if I can do better. Suggestions are welcome :-) > > > > None here. For big boxen that are highly idle, you'd likely want to > > shut down nodes and consolidate load, but otoh, all that slows response > > to burst, which I hate. I prefer race to idle, let power gating do its > > job. If I had a server farm with enough capacity vs load variability > > to worry about, I suspect I'd become highly interested in routing. > > I don't disagree for systems of that scale, but at the other end of the > spectrum it is a single SoC we are trying squeeze the best possible > mileage out of. That implies optimizing for power gating to reach deeper > C-states when possible by consolidating idle-time and grouping > idle cpus. Migrating task unnecessarily isn't helping us in achieving > that, unfortunately :-( Yup, the goals are pretty much mutually exclusive. For your goal, you want more of an allocator like behavior, where stacking of tasks is bad only once there's too much overlap (ie latency, defining is hard), and allocation always has the same order (expand rightward or such for the general case, adding little/big complexity for arm). For mine, current behavior is good, avoid stacking like the plague. -Mike