Received: by 2002:a25:4158:0:0:0:0:0 with SMTP id o85csp4697239yba; Wed, 10 Apr 2019 03:02:49 -0700 (PDT) X-Google-Smtp-Source: APXvYqzcktAciuXRgv8MLoH+jIMrFmRvHb/pHy50e3fSmzA0YyM59VvGcG6CkrOTe6xVq+gYXAuh X-Received: by 2002:a65:6210:: with SMTP id d16mr38861066pgv.110.1554890569447; Wed, 10 Apr 2019 03:02:49 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1554890569; cv=none; d=google.com; s=arc-20160816; b=XJ+LX2rozhxkV7hBc1S2k2GYYFu1utYWLIVK7Zh0xhmTeGHo6wKKLwUkN0vt8qDhxu HEnEb48ht7hBuANjECwnB4z302ra7rT05O4rGNfNWVineVNMLspPcZDmAHFkrgAQBuPq yiLZKRRs5W8qh934VYFhmKmS6p3qYLGlqkUcvd73Zz0doltqYDBuRuhB7tL21IxXUc/Q RoTvOGRUsVRmbneZmFC0lfx0CUTFRAxeJDvn6jgLh7wKlcdAtQXt0o3QxEOiytd6au/D hbtgU1vXz8aHPKjqXX/x3xE0vrI7Dz0KVJCd78AsPE3CersdxV6YH0pm9lLUfCSleRuz K0vw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date; bh=jJ7bNnH7bb50Q9Coq89fQ/AGue3tzeSfFx/mC/FML44=; b=b6bWZ6o5YpFvUJtCSzGc4NWA0TB7eCWj6nbU57rm1O6zEdzfYHTTbDiOCNv7sXJ+Vv Bg6at4NJwDGJa1r9i81DrYDxMVBE0kClxyXvx/uZFq80XNnLTwDq59MVmgGaNTjI55p9 us97UbOrzEDRarbRvVuoNJgzcEiRHm/c6V83g9wedC3dZwFg/PnDdpOJjtW+lzh4/swJ xmTCIeDLkMQb89m+3d5pqj4qe7r8GwlMkBDlZeXFhRcAR5CQkFUavEFJR426e4YJZ5/B OXsNPdU7kxYF7OitoBOp7YlIwXXV/mT6KEpfwTKKnR8+DVW9CUkurPPrRw/OsUu1xatJ FYCw== ARC-Authentication-Results: i=1; mx.google.com; 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 Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id r80si32601315pfa.128.2019.04.10.03.02.31; Wed, 10 Apr 2019 03:02:49 -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; 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 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729864AbfDJJ1a (ORCPT + 99 others); Wed, 10 Apr 2019 05:27:30 -0400 Received: from usa-sjc-mx-foss1.foss.arm.com ([217.140.101.70]:50612 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727964AbfDJJ12 (ORCPT ); Wed, 10 Apr 2019 05:27:28 -0400 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.72.51.249]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id BA994374; Wed, 10 Apr 2019 02:27:27 -0700 (PDT) Received: from e107158-lin.cambridge.arm.com (e107158-lin.cambridge.arm.com [10.1.194.71]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 8687C3F68F; Wed, 10 Apr 2019 02:27:26 -0700 (PDT) Date: Wed, 10 Apr 2019 10:27:23 +0100 From: Qais Yousef To: Valentin Schneider Cc: linux-kernel@vger.kernel.org, mingo@redhat.com, peterz@infradead.org, Dietmar.Eggemann@arm.com, morten.rasmussen@arm.com Subject: Re: [PATCH 1/2] sched/topology: build_sched_groups: Skip duplicate group rewrites Message-ID: <20190410092723.d4j4ctccogprtptg@e107158-lin.cambridge.arm.com> References: <20190409173546.4747-1-valentin.schneider@arm.com> <20190409173546.4747-2-valentin.schneider@arm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20190409173546.4747-2-valentin.schneider@arm.com> User-Agent: NeoMutt/20171215 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 04/09/19 18:35, Valentin Schneider wrote: > While staring at build_sched_domains(), I realized that get_group() > does several duplicate (thus useless) writes. > > If you take the Arm Juno r0 (LITTLEs = [0, 3, 4, 5], bigs = [1, 2]), the > sched_group build flow would look like this: > > ('MC[cpu]->sg' means 'per_cpu_ptr(&tl->data->sg, cpu)' with 'tl == MC') > > build_sched_groups(MC[CPU0]->sd, CPU0) > get_group(0) -> MC[CPU0]->sg > get_group(3) -> MC[CPU3]->sg > get_group(4) -> MC[CPU4]->sg > get_group(5) -> MC[CPU5]->sg > > build_sched_groups(DIE[CPU0]->sd, CPU0) > get_group(0) -> DIE[CPU0]->sg > get_group(1) -> DIE[CPU1]->sg <-----------------+ > | > build_sched_groups(MC[CPU1]->sd, CPU1) | > get_group(1) -> MC[CPU1]->sg | > get_group(2) -> MC[CPU2]->sg | > | > build_sched_groups(DIE[CPU1]->sd, CPU1) ^ > get_group(1) -> DIE[CPU1]->sg } We've set up these two up here! > get_group(3) -> DIE[CPU0]->sg } > > From this point on, we will only use sched_groups that have been > previously visited & initialized. The only new operation will > be which group pointer we affect to sd->groups. > > On the Juno r0 we get 32 get_group() calls, every single one of them > writing to a sched_group->cpumask. However, all of the data structures > we need are set up after 8 visits (see above). > > Return early from get_group() if we've already visited (and thus > initialized) the sched_group we're looking at. Overlapping domains > are not affected as they do not use build_sched_groups(). > > Tested on a Juno and a 2 * (Xeon E5-2690) system. > > Signed-off-by: Valentin Schneider > --- > FWIW I initially checked the refs for both sg && sg->sgc, but figured if > they weren't both 0 or > 1 then something must have gone wrong, so I > threw in a WARN_ON(). > --- > kernel/sched/topology.c | 12 +++++++++--- > 1 file changed, 9 insertions(+), 3 deletions(-) > > diff --git a/kernel/sched/topology.c b/kernel/sched/topology.c > index 64bec54ded3e..6c0b7326f66e 100644 > --- a/kernel/sched/topology.c > +++ b/kernel/sched/topology.c > @@ -1059,6 +1059,7 @@ static struct sched_group *get_group(int cpu, struct sd_data *sdd) > struct sched_domain *sd = *per_cpu_ptr(sdd->sd, cpu); > struct sched_domain *child = sd->child; > struct sched_group *sg; > + bool already_visited; > > if (child) > cpu = cpumask_first(sched_domain_span(child)); > @@ -1066,9 +1067,14 @@ static struct sched_group *get_group(int cpu, struct sd_data *sdd) > sg = *per_cpu_ptr(sdd->sg, cpu); > sg->sgc = *per_cpu_ptr(sdd->sgc, cpu); > > - /* For claim_allocations: */ > - atomic_inc(&sg->ref); > - atomic_inc(&sg->sgc->ref); > + /* Increase refcounts for claim_allocations: */ > + already_visited = atomic_inc_return(&sg->ref) > 1; > + /* sgc visits should follow a similar trend as sg */ > + WARN_ON(already_visited != (atomic_inc_return(&sg->sgc->ref) > 1)); NIT: I think it would be better to not have any side effect of calling WARN_ON(). Ie: do the atomic_inc_return() outside the WARN_ON() condition. Having two bool already_visited_sg and already_visited_sgc will make the code more readable too. Thanks -- Qais Yousef > + > + /* If we have already visited that group, it's already initialized. */ > + if (already_visited) > + return sg; > > if (child) { > cpumask_copy(sched_group_span(sg), sched_domain_span(child)); > -- > 2.20.1 >