Received: by 10.213.65.68 with SMTP id h4csp220873imn; Wed, 28 Mar 2018 02:13:33 -0700 (PDT) X-Google-Smtp-Source: AIpwx49j0GUj+tYlOoJQ95tMba52cMlb7Gj3qbyJKzsHFBbHvGTTAv8220RgDVbH4vUaJESkH5Up X-Received: by 2002:a17:902:64cf:: with SMTP id y15-v6mr3006605pli.49.1522228413067; Wed, 28 Mar 2018 02:13:33 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1522228413; cv=none; d=google.com; s=arc-20160816; b=SqBlmN46lz8Uc96c59b06RbdPULNyv2ftsGN65M5SoIPlDXskiKqGdFqBpY66t4TNT T6ojpHcOPXy3st3Z+/DK8SrmmlpDgkHuU1PDD9wdWRSWXS9h9PY9AvCEfZGEfTfkbeaT 1YjYzvBB7FfDdqBTo4loCwUbPG4g/qW5h5W70YppVn6StUNONwrfhlVsl67NVdoC9jdq AjjcMUpg0YRSeiJ8QTyIG3WVlvARbrCrSDTd/3kWjFBYG5Ht0P5rMRGWwv5St+ii0tnl 8V29qf648FeeIbOB3mModBD2RE61KhHw+v6rLJwRdw/KODvlFQ+QKv1xvfn8JPgITzxb RJdA== 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:arc-authentication-results; bh=lM37OShbeSxO2fcPiEXoYgJz1y2OrnqgMXJxdgwFfeQ=; b=i1Ggu52DLirH2SctCbhzQwGqJUulDw2BlqbnFDgWtlu9Un1kOefib7Mr1Nzx5GbqkS 0pgj6oMNROS2h2XsCaNPBjv39sQOmBPhRy2fH8IL8bD22y34/4tMZlf1CB7DaZTsnFbw WsJIjFv8zHEDNiwhgRgP1g6AxQj0n+sldq4ye3XvTFuslS7SicxVKQSKOdwkApgOeWu1 qTDiBormzaIbOY0BjY8DPWDJ3AsV7/cznLG2JLBFMioGWDAw/rN39cbSlMNZbHVxRC0g WzdEgYxnQPUExVG112zCkMRQjVeLixAffWah2bpngbEyPJcMEHB9JnJmSDoMI/rt0TTd sypg== 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 d1si2176314pgf.499.2018.03.28.02.13.17; Wed, 28 Mar 2018 02:13:33 -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 S1752120AbeC1JMR (ORCPT + 99 others); Wed, 28 Mar 2018 05:12:17 -0400 Received: from usa-sjc-mx-foss1.foss.arm.com ([217.140.101.70]:38550 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750774AbeC1JMQ (ORCPT ); Wed, 28 Mar 2018 05:12:16 -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 C991C15AB; Wed, 28 Mar 2018 02:12:15 -0700 (PDT) Received: from edgewater-inn.cambridge.arm.com (usa-sjc-imap-foss1.foss.arm.com [10.72.51.249]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPA id 9AC353F590; Wed, 28 Mar 2018 02:12:15 -0700 (PDT) Received: by edgewater-inn.cambridge.arm.com (Postfix, from userid 1000) id A66681AE53B0; Wed, 28 Mar 2018 10:12:26 +0100 (BST) Date: Wed, 28 Mar 2018 10:12:26 +0100 From: Will Deacon To: Vincent Guittot Cc: catalin.marinas@arm.com, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, peterz@infradead.org, dietmar.eggemann@arm.com, Morten.Rasmussen@arm.com, chris.redpath@arm.com Subject: Re: [PATCH] sched: support dynamiQ cluster Message-ID: <20180328091226.GD28871@arm.com> References: <1522223215-23524-1-git-send-email-vincent.guittot@linaro.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1522223215-23524-1-git-send-email-vincent.guittot@linaro.org> User-Agent: Mutt/1.5.23 (2014-03-12) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Mar 28, 2018 at 09:46:55AM +0200, Vincent Guittot wrote: > Arm DynamiQ system can integrate cores with different micro architecture > or max OPP under the same DSU so we can have cores with different compute > capacity at the LLC (which was not the case with legacy big/LITTLE > architecture). Such configuration is similar in some way to ITMT on intel > platform which allows some cores to be boosted to higher turbo frequency > than others and which uses SD_ASYM_PACKING feature to ensures that CPUs with > highest capacity, will always be used in priortiy in order to provide > maximum throughput. > > Add arch_asym_cpu_priority() for arm64 as this function is used to > differentiate CPUs in the scheduler. The CPU's capacity is used to order > CPUs in the same DSU. > > Create sched domain topolgy level for arm64 so we can set SD_ASYM_PACKING > at MC level. > > Some tests have been done on a hikey960 platform (quad cortex-A53, > quad cortex-A73). For the test purpose, the CPUs topology of the hikey960 > has been modified so the 8 heterogeneous cores are described as being part > of the same cluster and sharing resources (MC level) like with a DynamiQ DSU. > > Results below show the time in seconds to run sysbench --test=cpu with an > increasing number of threads. The sysbench test run 32 times > > without patch with patch diff > 1 threads 11.04(+/- 30%) 8.86(+/- 0%) -19% > 2 threads 5.59(+/- 14%) 4.43(+/- 0%) -20% > 3 threads 3.80(+/- 13%) 2.95(+/- 0%) -22% > 4 threads 3.10(+/- 12%) 2.22(+/- 0%) -28% > 5 threads 2.47(+/- 5%) 1.95(+/- 0%) -21% > 6 threads 2.09(+/- 0%) 1.73(+/- 0%) -17% > 7 threads 1.64(+/- 0%) 1.56(+/- 0%) - 7% > 8 threads 1.42(+/- 0%) 1.42(+/- 0%) 0% > > Results show a better and stable results across iteration with the patch > compared to mainline because we are always using big cores in priority whereas > with mainline, the scheduler randomly choose a big or a little cores when > there are more cores than number of threads. > With 1 thread, the test duration varies in the range [8.85 .. 15.86] for > mainline whereas it stays in the range [8.85..8.87] with the patch > > Signed-off-by: Vincent Guittot > > --- > > The SD_ASYM_PACKING flag is disabled by default and I'm preparing another patch > to enable this dynamically at boot time by detecting the system topology. > > arch/arm64/kernel/topology.c | 30 ++++++++++++++++++++++++++++++ > 1 file changed, 30 insertions(+) > > diff --git a/arch/arm64/kernel/topology.c b/arch/arm64/kernel/topology.c > index 2186853..cb6705e5 100644 > --- a/arch/arm64/kernel/topology.c > +++ b/arch/arm64/kernel/topology.c > @@ -296,6 +296,33 @@ static void __init reset_cpu_topology(void) > } > } > > +#ifdef CONFIG_SCHED_MC > +unsigned int __read_mostly arm64_sched_asym_enabled; > + > +int arch_asym_cpu_priority(int cpu) > +{ > + return topology_get_cpu_scale(NULL, cpu); > +} > + > +static inline int arm64_sched_dynamiq(void) > +{ > + return arm64_sched_asym_enabled ? SD_ASYM_PACKING : 0; > +} > + > +static int arm64_core_flags(void) > +{ > + return cpu_core_flags() | arm64_sched_dynamiq(); > +} > +#endif > + > +static struct sched_domain_topology_level arm64_topology[] = { > +#ifdef CONFIG_SCHED_MC > + { cpu_coregroup_mask, arm64_core_flags, SD_INIT_NAME(MC) }, Maybe stick this in a macro to avoid the double #ifdef? Will