Received: by 2002:a25:31c3:0:0:0:0:0 with SMTP id x186csp1048493ybx; Wed, 30 Oct 2019 09:05:10 -0700 (PDT) X-Google-Smtp-Source: APXvYqzxeCblp0eq2c5Mku2Qp1PqIVcrJkeFSh3U51ymsyS6jQrbX4yrxV2oSSLYDd3P7m6uSEkb X-Received: by 2002:a50:f74b:: with SMTP id j11mr429707edn.71.1572451509919; Wed, 30 Oct 2019 09:05:09 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1572451509; cv=none; d=google.com; s=arc-20160816; b=kxAhKavyVGNiJyhZvljomL4iSKkG34HvLtdZh0WYg7o0y/15ajorvNtBatmFZTBmLs tlEx5LtslRc6iCTfRCjNy87IYg6O9jZyyg0nw1p+IIBhZRDxcddk5AXZkya2EydoTYBW PyZ/JYPUtj/pEjF69U9z2ufu3LaoK17MjaRTeGQiSdHEaDBuBmy1OUM6fPWN0WENVEx4 H+BRgSJWHIB0qlKs9cyCFZT/4YT4V9N5SE3lSoEOIu66lmzFRWSTfrcL0KfH52PvXdST YrWuBbE9MPP/p1tNHec4H5Ft+1kb64LoFO4aXXfWjTxa+/tP5vJD8XVM/VvN0D57+/N7 5a7A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:dkim-signature; bh=ZmX4zrjZaoAtWMG4pGTvgGDFz+UMFVGZubr8Y23HkjY=; b=R5jDEd+dkZo/BwwM0NRkfDGx2HGpF74WfLATWImFfT8ZpUujx4NcrljAJMjZ4GCCql ZpHdkMISGLK1/QQ0SSuNjXMrAbNeoRp4+VpeTwViYL2AGveq0Waz7zi0mJZO4sIDbarv hg3Ksl3MwhuvXxByvfqWoplAVY/V41brd7+QEryvZONYUpkscHkSE31RGnE7nCT92TCn 3+HL5enz42Zcovmk0ijSLMl1NEvkG8XND+ZcNadPVW3L+C2L3AcolQHtIVEswqeR6uVW pIkkvGbas3qd5VQ+RNcSh/n7b0nXjDnz1zfD/2khhk3AmcpBTLudqg6Wo9CV3cYEcLBY 7tIw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linaro.org header.s=google header.b=O4+Pdt11; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linaro.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id l12si2002406edk.60.2019.10.30.09.04.41; Wed, 30 Oct 2019 09:05:09 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@linaro.org header.s=google header.b=O4+Pdt11; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linaro.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727499AbfJ3QDk (ORCPT + 99 others); Wed, 30 Oct 2019 12:03:40 -0400 Received: from mail-lj1-f196.google.com ([209.85.208.196]:35552 "EHLO mail-lj1-f196.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727064AbfJ3QDj (ORCPT ); Wed, 30 Oct 2019 12:03:39 -0400 Received: by mail-lj1-f196.google.com with SMTP id m7so3314251lji.2 for ; Wed, 30 Oct 2019 09:03:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=ZmX4zrjZaoAtWMG4pGTvgGDFz+UMFVGZubr8Y23HkjY=; b=O4+Pdt11PD3uMpUXHaugaoxBTMgYtjANyaD2bpiuvaJ/l6Udb9TaF8SdCk6dzbhynu VxvQPLq+aXlsYwHm56zndbzxvWgxvmC+H7olT7D2c8JtFFcUuEO5LUxwPVwXpKK1dvSE CXScqaBnPdkR9tyGz1j/LudnlhiEXUBIuVgra8m/XTl2rzxZ4jEJNrKPDpDpleBqLU39 WxJoDvKUUE/Yu+lDV/3fO5Gbd8W5wvVJQIWRtcStdrulCiPbhAhzfUmn0Y0HnX1VJb2A ou52D9RZXz7qDje6euuMEHGJB7okK9YykJoxFLhd7/tNV94p9uMwawhXUeg22hl/SmcJ XsbQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=ZmX4zrjZaoAtWMG4pGTvgGDFz+UMFVGZubr8Y23HkjY=; b=hOhrRc6ASzPPTPv7UVtB5w5C0nqVdgmR1QeAc8HzUC01YKMx9Kamz13a67wk1WSx1z O1FzdWDHPudg4Pw5QIG+L7dmeM/Qq27Yv4j+kfpDRcioN0yyjC0ItgZbtHkzIcIaxhyt Q7QmNr8SJt/7ayZZh19hNjsNVN3ZPcFX/Di75yb2zOqrIVpN1tqC/ppxqhZA1cqKc0LW a3cme69BnRMd/ccrwcjtFf3S2WMN5L6mkO3xHOkjrAPNkJR7nyPYWs0Zxw8//+UfMINa RzgipwYyqqLFdsqH7a0mmJ67julvvPSNu9YAorXehmuURHzmxnOK/t29lHJXmGA+5E6I 7nGA== X-Gm-Message-State: APjAAAVTjGZNjuG+7BLoar3tyvQb1ttMoPKYSLghjsD5urJvt9P+3Kvz x13yv96VNC+laYtT2ZKjOjqNStjqi1+vss65MqVdizCBnNc= X-Received: by 2002:a2e:96c1:: with SMTP id d1mr363547ljj.87.1572451416530; Wed, 30 Oct 2019 09:03:36 -0700 (PDT) MIME-Version: 1.0 References: <1571405198-27570-1-git-send-email-vincent.guittot@linaro.org> <1571405198-27570-2-git-send-email-vincent.guittot@linaro.org> <20191030145133.GH3016@techsingularity.net> In-Reply-To: <20191030145133.GH3016@techsingularity.net> From: Vincent Guittot Date: Wed, 30 Oct 2019 17:03:24 +0100 Message-ID: Subject: Re: [PATCH v4 01/11] sched/fair: clean up asym packing To: Mel Gorman Cc: linux-kernel , Ingo Molnar , Peter Zijlstra , Phil Auld , Valentin Schneider , Srikar Dronamraju , Quentin Perret , Dietmar Eggemann , Morten Rasmussen , Hillf Danton , Parth Shah , Rik van Riel Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, 30 Oct 2019 at 15:51, Mel Gorman wrote: > > On Fri, Oct 18, 2019 at 03:26:28PM +0200, Vincent Guittot wrote: > > Clean up asym packing to follow the default load balance behavior: > > - classify the group by creating a group_asym_packing field. > > - calculate the imbalance in calculate_imbalance() instead of bypassing it. > > > > We don't need to test twice same conditions anymore to detect asym packing > > and we consolidate the calculation of imbalance in calculate_imbalance(). > > > > There is no functional changes. > > > > Signed-off-by: Vincent Guittot > > Acked-by: Rik van Riel > > --- > > kernel/sched/fair.c | 63 ++++++++++++++--------------------------------------- > > 1 file changed, 16 insertions(+), 47 deletions(-) > > > > diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c > > index 1f0a5e1..617145c 100644 > > --- a/kernel/sched/fair.c > > +++ b/kernel/sched/fair.c > > @@ -7675,6 +7675,7 @@ struct sg_lb_stats { > > unsigned int group_weight; > > enum group_type group_type; > > int group_no_capacity; > > + unsigned int group_asym_packing; /* Tasks should be moved to preferred CPU */ > > unsigned long group_misfit_task_load; /* A CPU has a task too big for its capacity */ > > #ifdef CONFIG_NUMA_BALANCING > > unsigned int nr_numa_running; > > @@ -8129,9 +8130,17 @@ static bool update_sd_pick_busiest(struct lb_env *env, > > * ASYM_PACKING needs to move all the work to the highest > > * prority CPUs in the group, therefore mark all groups > > * of lower priority than ourself as busy. > > + * > > + * This is primarily intended to used at the sibling level. Some > > + * cores like POWER7 prefer to use lower numbered SMT threads. In the > > + * case of POWER7, it can move to lower SMT modes only when higher > > + * threads are idle. When in lower SMT modes, the threads will > > + * perform better since they share less core resources. Hence when we > > + * have idle threads, we want them to be the higher ones. > > */ > > if (sgs->sum_nr_running && > > sched_asym_prefer(env->dst_cpu, sg->asym_prefer_cpu)) { > > + sgs->group_asym_packing = 1; > > if (!sds->busiest) > > return true; > > > > (I did not read any of the earlier implementations of this series, maybe > this was discussed already in which case, sorry for the noise) > > Are you *sure* this is not a functional change? > > Asym packing is a twisty maze of headaches and I'm not familiar enough > with it to be 100% certain without spending a lot of time on this. Even > spotting how Power7 ends up using asym packing with lower-numbered SMT > threads is a bit of a challenge. Specifically, it relies on the scheduler > domain SD_ASYM_PACKING flag for SMT domains to use the weak implementation > of arch_asym_cpu_priority which by defaults favours the lower-numbered CPU. > > The check_asym_packing implementation checks that flag but I can't see > the equiavlent type of check here. update_sd_pick_busiest could be called The checks of SD_ASYM_PACKING and CPU_NOT_IDLE are already above in the function but out of the patch. In fact this part of update_sd_pick_busiest is already dedicated to asym_packing. What I'm doing is that instead of checking asym_packing in update_sd_pick_busiest and then rechecking the same thing in find_busiest_group, I save the check result and reuse it Also patch 04 moves further this code > for domains that span NUMA or basically any domain that does not specify > SD_ASYM_PACKING and end up favouring a lower-numbered CPU (or whatever > arch_asym_cpu_priority returns in the case of x86 which has a different > idea for favoured CPUs). > > sched_asym_prefer appears to be a function that is very easy to use > incorrectly. Should it take env and check the SD flags first? > > -- > Mel Gorman > SUSE Labs