From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1423773Ab2LFPNT (ORCPT ); Thu, 6 Dec 2012 10:13:19 -0500 Received: from mga02.intel.com ([134.134.136.20]:14110 "EHLO mga02.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1423760Ab2LFPNR (ORCPT ); Thu, 6 Dec 2012 10:13:17 -0500 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="4.84,230,1355126400"; d="scan'208";a="253016885" Message-ID: <50C0B5FD.6000200@intel.com> Date: Thu, 06 Dec 2012 23:13:01 +0800 From: Alex Shi User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:15.0) Gecko/20120912 Thunderbird/15.0.1 MIME-Version: 1.0 To: Mike Galbraith CC: Alex Shi , Ingo Molnar , Peter Zijlstra , Paul Turner , lkml , Vincent Guittot , Preeti U Murthy , Andrew Morton , Arjan van de Ven , Tejun Heo Subject: Re: weakness of runnable load tracking? References: <50C00D41.1010800@intel.com> <1354773465.4593.61.camel@marge.simpson.net> <50C05201.7090900@intel.com> <1354785141.4593.109.camel@marge.simpson.net> In-Reply-To: <1354785141.4593.109.camel@marge.simpson.net> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 12/06/2012 05:12 PM, Mike Galbraith wrote: > On Thu, 2012-12-06 at 16:06 +0800, Alex Shi wrote: >>>> >>>> Hi Paul & Ingo: >>>> >>>> In a short word of this issue: burst forking/waking tasks have no time >>>> accumulate the load contribute, their runnable load are taken as zero. >>>> that make select_task_rq do a wrong decision on which group is idlest. >>> >>> As you pointed out above, new tasks can (and imho should) be born with >>> full weight. Tasks _may_ become thin, but they're all born hungry. >> >> Thanks for comments. I think so. :) >>> >>>> There is still 3 kinds of solution is helpful for this issue. >>>> >>>> a, set a unzero minimum value for the long time sleeping task. but it >>>> seems unfair for other tasks these just sleep a short while. >>>> >>>> b, just use runnable load contrib in load balance. Still using >>>> nr_running to judge idlest group in select_task_rq_fair. but that may >>>> cause a bit more migrations in future load balance. >>>> >>>> c, consider both runnable load and nr_running in the group: like in the >>>> searching domain, the nr_running number increased a certain number, like >>>> double of the domain span, in a certain time. we will think it's a burst >>>> forking/waking happened, then just count the nr_running as the idlest >>>> group criteria. >>>> >>>> IMHO, I like the 3rd one a bit more. as to the certain time to judge if >>>> a burst happened, since we will calculate the runnable avg at very tick, >>>> so if increased nr_running is beyond sd->span_weight in 2 ticks, means >>>> burst happening. What's your opinion of this? >>>> >>>> Any comments are appreciated! >>> >>> IMHO, for fork and bursty wake balancing, the only thing meaningful is >>> the here and now state of runqueues tasks are being dumped into. >>> >>> Just because tasks are historically short running, you don't necessarily >>> want to take a gaggle and wedge them into a too small group just to even >>> out load averages. If there was a hole available that you passed up by >>> using average load, you lose utilization. I can see how this load >>> tracking stuff can average out to a win on a ~heavily loaded box, but >>> bursty stuff I don't see how it can do anything but harm, so imho, the >>> user should choose which is best for his box, instantaneous or history. >> >> Do you mean the system administrator need to do this choice? > > That's my gut feeling just from pondering potential pitfalls. > >> It's may a hard decision. :) > > Yup, very hard. > >> Any suggestions of decision basis? > > Same as most buttons.. poke it and see what happens :) :D > >>> WRT burst detection: any window you define can be longer than the burst. >> >> Maybe we can define 2 waking on same cpu in 1 tick is a burst happened, >> and if the cpu had taken a waking task. we'd better skip this cpu. :) >> Anyway, the hard point is we can not predict future. > > No matter what the metric, you'll be reacting after the fact. > > Somebody needs to code up that darn omniscience algorithm. In a pinch, > a simple undo the past will suffice :) Yes. I see. > > -Mike > -- Thanks Alex