From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932264AbcEKJ4o (ORCPT ); Wed, 11 May 2016 05:56:44 -0400 Received: from mail-wm0-f66.google.com ([74.125.82.66]:33956 "EHLO mail-wm0-f66.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751348AbcEKJ4m (ORCPT ); Wed, 11 May 2016 05:56:42 -0400 Message-ID: <1462960599.3961.53.camel@gmail.com> Subject: Re: sched: tweak select_idle_sibling to look for idle threads From: Mike Galbraith To: Yuyang Du Cc: Peter Zijlstra , Chris Mason , Ingo Molnar , Matt Fleming , linux-kernel@vger.kernel.org Date: Wed, 11 May 2016 11:56:39 +0200 In-Reply-To: <20160511012347.GA8790@intel.com> References: <1462765540.3803.44.camel@suse.de> <20160508202201.GM16093@intel.com> <1462779853.3803.128.camel@suse.de> <20160509011311.GQ16093@intel.com> <1462786745.3803.181.camel@suse.de> <20160509232623.GR16093@intel.com> <1462866562.3702.33.camel@suse.de> <1462893965.3702.56.camel@gmail.com> <20160510191646.GA4870@intel.com> <1462940271.3717.57.camel@gmail.com> <20160511012347.GA8790@intel.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 Wed, 2016-05-11 at 09:23 +0800, Yuyang Du wrote: > > Yeah, just like everything else, it'll cuts both ways (why you can't > > win the sched game). If I can believe tbench, at tasks=cpus, reducing > > lag increased utilization and reduced latency a wee bit, as did the > > reserve thing once a booboo got fixed up. > > Ok, so you have a secret IDLE_RESERVE? Good luck and show it, ;) Nothing sexy, just cpmxchg(), with the obvious test/set/clear spots. cmpxchg(&cpu_rq(cpu)->idle_latch, cpu, nr_cpu_ids) > Depends on the goal. For both, load lagging reality means the high > > frequency component is squelched, meaning less migration cost, but also > > higher latency due to stacking. It's a tradeoff where Chris' latency > > is everything" benchmark, and _maybe_ the real world load it's based > > upon is on Peter's end of the rob Peter to pay Paul transaction. The > > benchmark says it definitely is, the real world load may have already > > been fixed up by the select_idle_sibling() rewrite. > > Obviously, load avgs are good at balancing in a larger scale in a timeframe, > so they should be used in comparing/balancing sd's not cpus. However, this > is not the case currently: avgs are mixed with idle cpu/core selection, so > I think better job can be done before and after select_idle_sibling(). > > For example, I don't know what the complex wake_affine() is really doing for > what. Am i missing something, you think? wake_affine() just says no to keep us from pulling the whole load to one cache, starting massive tug-o-war with LB and nuking throughput. Everybody wants hot data, but they can't all have it and scale. -Mike