Received: by 10.223.164.202 with SMTP id h10csp4321721wrb; Wed, 29 Nov 2017 04:40:46 -0800 (PST) X-Google-Smtp-Source: AGs4zMYU5CsYNdtt2eCimzWH2JCXH3yfb+krn+8PTTk3mhBixC6eQE6H5/u353GSfC9XGHOn0iRt X-Received: by 10.99.39.5 with SMTP id n5mr2745955pgn.48.1511959246615; Wed, 29 Nov 2017 04:40:46 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1511959246; cv=none; d=google.com; s=arc-20160816; b=Xbh1iT+LdToDj2zesLc5P0caAJrPeNei0dsagOKe3sR3YimLSAMaiyMJYTA6wEOs3T iBMXjVuV33nKSboi6R9s7uYw8pRcCS3Y09d+SMsDsY2H/FewENmZ9b1sPEM07deho4SJ tO1Q0XZ1YhQ/t9chmPjPiuS5PN5t8RW7WdrjgQciJ0IHw7ef+GItfkJlS8XXomMbgkH2 3QoJuW/nXKAHUdEfCK3dwjmtpBvkZgDqyeZ6nVT9JKm6I5Or7EdN06Pj5gwcIKupZLHE 4PH5YlCYN0+WKp7zUOhmPOzc79NHGcx/FCuayuxl7ES1LdePVVT8+RY9FenxN21gWAWq FsDQ== 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 :references:in-reply-to:mime-version:dkim-signature :arc-authentication-results; bh=ExNPzvg6D8bms+131iuWh1au8sHoiJaJ10bGran2QgA=; b=XqwrnS4/Tn7vLnQcTDitSQtusARWdIi8Dvocl2FXvuB2t8Zwc2eJ8IKdR+/vCHdA4j A/BjmcKukerlFxTzSarVGYgzwZw4XCZDXdewtqfHb/io9JfhBsd63RgzTwn6hkh74JV4 rlTv48GGpuW3EoRjXfDzmc6y7WbECuncYL+FUt8+wF50fJJHLWiYpjYvPzp2fpnWpdhI f2+ZVxSk/y3amDxg1VkugH5xEJcj+dgQPTtromLzgG+vDHAUqam1b+/nMK5YEkvJRv0r dBhZqN1ONn8xrLqNdiUiuJCk9ktydYk36m+U3dh2yhUk7JgN4PE81fzscakou1YifyMt rGKg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linaro.org header.s=google header.b=QChVnpIe; 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 f28si1200366pgn.758.2017.11.29.04.40.34; Wed, 29 Nov 2017 04:40:46 -0800 (PST) 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=QChVnpIe; 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 S932082AbdK2JZV (ORCPT + 70 others); Wed, 29 Nov 2017 04:25:21 -0500 Received: from mail-it0-f66.google.com ([209.85.214.66]:46607 "EHLO mail-it0-f66.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753014AbdK2JZS (ORCPT ); Wed, 29 Nov 2017 04:25:18 -0500 Received: by mail-it0-f66.google.com with SMTP id t1so3219313ite.5 for ; Wed, 29 Nov 2017 01:25:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=ExNPzvg6D8bms+131iuWh1au8sHoiJaJ10bGran2QgA=; b=QChVnpIe66/q/7xRFzpY4umTr6In15cwYK7bxewNjBD6hE4rBywIBCZuris78nH7MI k9xRThn9ICMeDms80ymXE74jl7WPuOIwxa+hbH9v/eeJj4vmtFPaNDzomxc3iHup145s icUkXaEDy7WsGPMk3pc9VHJzOgcs5nFeQGTtk= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=ExNPzvg6D8bms+131iuWh1au8sHoiJaJ10bGran2QgA=; b=RLvueR7F1jbVqKY+YIydqG26a1PUk9gIAbdVuHphARLpbID4tpTRoHRAOZBPWcEti+ qPO0XqMrGTQn9IEJqnVh/ekQ3IUgPEa+9lG/T8GDzyS+j69tmL9Pwf9kNvCN/ED3m2WO FskNoEvvGZ3kLlTIBV/FR0/311LkqaFgKEOeUGVkrsxevDugz267IoxyAEukcILU0Hvd 6dkOPwf9OxoLeIyRCTqMTjrmBjAOA1SaEiiWSvOyYSVfBpnFYbQf/QtotpKQCTCm2UsU w7WiTr+A5AT/4/lo/jqVOypL95XOyxLGyH0NVX46JKxJ6qsO4+r4bV4tvLt5VuPgHsGy 0KXQ== X-Gm-Message-State: AJaThX4RExRu06Ka/VmUYouFsSCjPAXZkCX1vc/6h0ACGOFivke8F8pt U6oLEJ8gq5hfK4vgGiRrAQOKcstikEwyr5qLqwYb2DiOF08= X-Received: by 10.36.237.202 with SMTP id r193mr6662406ith.74.1511947517639; Wed, 29 Nov 2017 01:25:17 -0800 (PST) MIME-Version: 1.0 Received: by 10.107.101.14 with HTTP; Wed, 29 Nov 2017 01:24:57 -0800 (PST) In-Reply-To: <1511803767-24572-1-git-send-email-morten.rasmussen@arm.com> References: <1511803767-24572-1-git-send-email-morten.rasmussen@arm.com> From: Vincent Guittot Date: Wed, 29 Nov 2017 10:24:57 +0100 Message-ID: Subject: Re: [PATCH] sched/topology: Set SD_PREFER_SIBLING consistently on non-NUMA levels To: Morten Rasmussen Cc: Peter Zijlstra , "mingo@redhat.com" , Dietmar Eggemann , mgalbraith@suse.de, linux-kernel 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 Hi Morten, On 27 November 2017 at 18:29, Morten Rasmussen wrote: > SD_PREFER_SIBLING adds an additional bias towards spreading tasks on the > _parent_ sched_domain even if a sched_group isn't overloaded. It is > currently set on: > > 1. SMT level to promote spreading to sibling cores rather than using > sibling HW-threads (caff37ef96eac7fe96a). > > 2. Non-NUMA levels which don't have the SD_SHARE_PKG_RESOURCES flag > set (= DIE level in the default topology) as it was found to > improve benchmarks on certain NUMA systems (6956dc568f34107f1d02b). So the goal is to have the last non-NUMA level with the flag so we can spread between "DIE" > > 3. Any non-NUMA level that inherits the flag due to elimination of > its parent sched_domain level in the de-generate step of the > sched_domain hierarchy set up (= MC level in the default > topology). This is to ensure that the last non NUMA level has the flag when the DIE one disappears but the goal is the same as 2. > > Preferring siblings seems to be a useful tweak for all non-NUMA levels, > so we should enable it on all non-NUMA levels. As it is, it is possible > to have it SMT and DIE, but not MC in between when using the default > topology. So you want to extend it to all non NUMA level. And especially you want to spread tasks in each MC groups when we have DIE and MC levels. Have you got benchmark results to show improvement or is it just to align topology configuration? The fact that this flag improves bench for SMT and NUMA level doesn't mean that it will improve for MC level as well. We have the wake_wide/wake_affine stuffs that tries to do similar thing dynamically and it regularly improves/regresses benchmark like sysbench or hackbench > > Signed-off-by: Morten Rasmussen > cc: Ingo Molnar > cc: Peter Zijlstra > --- > kernel/sched/topology.c | 5 ++--- > 1 file changed, 2 insertions(+), 3 deletions(-) > > diff --git a/kernel/sched/topology.c b/kernel/sched/topology.c > index 6798276d29af..7f70806bfa0f 100644 > --- a/kernel/sched/topology.c > +++ b/kernel/sched/topology.c > @@ -1122,7 +1122,7 @@ sd_init(struct sched_domain_topology_level *tl, > | 0*SD_SHARE_CPUCAPACITY > | 0*SD_SHARE_PKG_RESOURCES > | 0*SD_SERIALIZE > - | 0*SD_PREFER_SIBLING > + | 1*SD_PREFER_SIBLING > | 0*SD_NUMA > | sd_flags > , > @@ -1153,7 +1153,6 @@ sd_init(struct sched_domain_topology_level *tl, > } > > if (sd->flags & SD_SHARE_CPUCAPACITY) { > - sd->flags |= SD_PREFER_SIBLING; > sd->imbalance_pct = 110; > sd->smt_gain = 1178; /* ~15% */ > > @@ -1168,6 +1167,7 @@ sd_init(struct sched_domain_topology_level *tl, > sd->busy_idx = 3; > sd->idle_idx = 2; > > + sd->flags &= ~SD_PREFER_SIBLING; > sd->flags |= SD_SERIALIZE; > if (sched_domains_numa_distance[tl->numa_level] > RECLAIM_DISTANCE) { > sd->flags &= ~(SD_BALANCE_EXEC | > @@ -1177,7 +1177,6 @@ sd_init(struct sched_domain_topology_level *tl, > > #endif > } else { > - sd->flags |= SD_PREFER_SIBLING; > sd->cache_nice_tries = 1; > sd->busy_idx = 2; > sd->idle_idx = 1; > -- > 2.7.4 > From 1585401684665855732@xxx Wed Nov 29 12:01:07 +0000 2017 X-GM-THRID: 1585241247547824571 X-Gmail-Labels: Inbox,Category Forums,HistoricalUnread