Received: by 2002:a05:6a10:6d10:0:0:0:0 with SMTP id gq16csp884979pxb; Fri, 22 Apr 2022 13:25:08 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwu5M9/fywct89NsB+bdUuZ6E3vEkNk5chPYIplo1jiS35Ef5l+6IAXh1GBffk3jgDRok12 X-Received: by 2002:a63:6c01:0:b0:3aa:f59e:3799 with SMTP id h1-20020a636c01000000b003aaf59e3799mr211555pgc.536.1650659108233; Fri, 22 Apr 2022 13:25:08 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1650659108; cv=none; d=google.com; s=arc-20160816; b=KcNwKtaOD3QxAQSXcFcIekb+E6zvrzng6WI0lNwSeoLViXVMUeXlYv1qqyMR75PdTk Itso31Rfw/QilSiWvJ4Ghmko4go+wPP3Z3rL7yIH/cn34Ltxgn2Tzj0GNr1x3L3PYXA+ f05d+AyEvFRwrJc29eGbsV8F6DhxfDTeNdwg3r/HlDtpgIK2dz25YEY15tfevkEgbX8E 8MUvc9Ydi2YCpm55S+/fHkQrjxu3VcYYZGhzByqp2xMWRJ6JH8ojJeuiV9ltGlj6XGna ZvIH3QR2/7fG+Irf+EvT+kjzU4lxEX7e9r1nj7I+bb/BzGotTMHaR6fBW/aTUbAFhgTv 32HQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-transfer-encoding :content-disposition:mime-version:references:message-id:subject:cc :to:from:date:dkim-signature; bh=YL1xRS2kwa46JNch9DPM/4cMrmezS0vLUI6nlohcUJI=; b=kv8VTeQiCPHcNJjMLNft4J9wP9F04pwRs5CynB8JG0af+fGEFa4XumtiDMbT0cfqlZ aH2WkYep7v+O/atso0cGR/nO54MPTb1+zyYpr7DpdzW6zB0TKjWCXBW+5YY9vh556fbF FSoJkx6XlJ8I+BO1kNIxSchCSyQQ8AsIVjqsT1ndIve41WNqqWwMdLl1YMHfXoBQpcRE 8kncdDi20UcavNIJ4QsMX7ljLR8kp4w2CbMMH5noL9SmWQxe82pzmlOpXEMkjQyCMgBm rGpbVo+8k+2pj0iolzkgzsPmArtHye3dgSVwnwRsMrtxTryTFQ6IJV7RHYaV3sMmYcGq J2HA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linuxfoundation.org header.s=korg header.b=L2nERJK9; spf=softfail (google.com: domain of transitioning linux-kernel-owner@vger.kernel.org does not designate 23.128.96.19 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linuxfoundation.org Return-Path: Received: from lindbergh.monkeyblade.net (lindbergh.monkeyblade.net. [23.128.96.19]) by mx.google.com with ESMTPS id 32-20020a17090a09a300b001cb73339defsi10772343pjo.183.2022.04.22.13.25.07 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 22 Apr 2022 13:25:08 -0700 (PDT) Received-SPF: softfail (google.com: domain of transitioning linux-kernel-owner@vger.kernel.org does not designate 23.128.96.19 as permitted sender) client-ip=23.128.96.19; Authentication-Results: mx.google.com; dkim=pass header.i=@linuxfoundation.org header.s=korg header.b=L2nERJK9; spf=softfail (google.com: domain of transitioning linux-kernel-owner@vger.kernel.org does not designate 23.128.96.19 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linuxfoundation.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id D8036270CAC; Fri, 22 Apr 2022 12:13:12 -0700 (PDT) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1447529AbiDVMeS (ORCPT + 99 others); Fri, 22 Apr 2022 08:34:18 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:49980 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1447540AbiDVMeO (ORCPT ); Fri, 22 Apr 2022 08:34:14 -0400 Received: from ams.source.kernel.org (ams.source.kernel.org [145.40.68.75]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 2A03254BC3 for ; Fri, 22 Apr 2022 05:31:21 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ams.source.kernel.org (Postfix) with ESMTPS id C7EB8B82CD3 for ; Fri, 22 Apr 2022 12:31:19 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 8F9C5C385A0; Fri, 22 Apr 2022 12:31:17 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1650630678; bh=B0FfGg08Iiv7pykm+jqHRmeXsu0/oIWa+m7eEXoWwkw=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=L2nERJK9AIVns/WkGlmLNC2c0DHBsR2l7dmulew/h50tXqj/il0W9O8w3l6g4D8eu rw3FJgrMlX1iTWHTgTi2Rq6ZenQTltxBlddZ1j8kakP4r2acTqS5MzsX4n1sVDiQi0 /8bu0EvNgrs1wWyh1Q18lCgHHMWUsEEHiZ0PR40Y= Date: Fri, 22 Apr 2022 14:31:14 +0200 From: Greg Kroah-Hartman To: Qing Wang Cc: Catalin Marinas , Will Deacon , Sudeep Holla , "Rafael J. Wysocki" , linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, vincent.guittot@linaro.org, dietmar.eggemann@arm.com Subject: Re: [PATCH V2 2/2] arm64: Add complex scheduler level for arm64 Message-ID: References: <1650628289-67716-1-git-send-email-wangqing@vivo.com> <1650628289-67716-3-git-send-email-wangqing@vivo.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <1650628289-67716-3-git-send-email-wangqing@vivo.com> X-Spam-Status: No, score=-2.5 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,RDNS_NONE,SPF_HELO_NONE autolearn=unavailable autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Apr 22, 2022 at 04:51:26AM -0700, Qing Wang wrote: > From: Wang Qing > > The DSU-110 DynamIQâ„¢ cluster supports blocks that are called complexes > which contain up to two cores of the same type and some shared logic. > Sharing some logic between the cores can make a complex area efficient. > > This patch adds complex level for complexs and automatically enables > the load balance among complexs. It will directly benefit a lot of > workload which loves more resources such as memory bandwidth, caches. > > Testing has been done with Stream benchmark: > 8threads stream (2 little cores * 2(complex) + 3 medium cores + 1 big core) > stream stream > w/o patch w/ patch > MB/sec copy 37579.2 ( 0.00%) 39127.3 ( 4.12%) > MB/sec scale 38261.1 ( 0.00%) 39195.4 ( 2.44%) > MB/sec add 39497.0 ( 0.00%) 41101.5 ( 4.06%) > MB/sec triad 39885.6 ( 0.00%) 40772.7 ( 2.22%) > > And in order to support this features, we defined arm64_topology. > > V2: > fix commit log and loop more > > Signed-off-by: Wang Qing > --- > arch/arm64/Kconfig | 13 +++++++++++ > arch/arm64/kernel/smp.c | 48 ++++++++++++++++++++++++++++++++++++++++- > 2 files changed, 60 insertions(+), 1 deletion(-) > > diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig > index edbe035cb0e3..4063de8c6153 100644 > --- a/arch/arm64/Kconfig > +++ b/arch/arm64/Kconfig > @@ -1207,6 +1207,19 @@ config SCHED_CLUSTER > by sharing mid-level caches, last-level cache tags or internal > busses. > > +config SCHED_COMPLEX > + bool "Complex scheduler support" > + help > + DSU supports blocks that are called complexes which contain up to > + two cores of the same type and some shared logic. Sharing some logic > + between the cores can make a complex area efficient. > + > + Complex also can be considered as a shared cache group smaller > + than cluster. > + > + Complex scheduler support improves the CPU scheduler's decision > + making when dealing with machines that have complexs of CPUs. > + > config SCHED_SMT > bool "SMT scheduler support" > help > diff --git a/arch/arm64/kernel/smp.c b/arch/arm64/kernel/smp.c > index 3b46041f2b97..526765112146 100644 > --- a/arch/arm64/kernel/smp.c > +++ b/arch/arm64/kernel/smp.c > @@ -14,6 +14,7 @@ > #include > #include > #include > +#include > #include > #include > #include > @@ -57,6 +58,10 @@ > DEFINE_PER_CPU_READ_MOSTLY(int, cpu_number); > EXPORT_PER_CPU_SYMBOL(cpu_number); > > +#ifdef SCHED_COMPLEX > +DEFINE_PER_CPU_READ_MOSTLY(cpumask_t, cpu_complex_map); > +#endif ifdefs should not be in .c files. > + > /* > * as from 2.5, kernels no longer have an init_tasks structure > * so we need some other way of telling a new secondary core > @@ -715,6 +720,47 @@ void __init smp_init_cpus(void) > } > } > > +#ifdef SCHED_COMPLEX same here. > +static int arm64_complex_flags(void) > +{ > + return SD_SHARE_PKG_RESOURCES; > +} > + > +const struct cpumask *arm64_complex_mask(int cpu) > +{ > + const struct cpumask *core_mask = cpu_cpu_mask(cpu); > + > + /* Find the smaller shared cache level than clustergroup and coregroup*/ > +#ifdef CONFIG_SCHED_MC > + core_mask = cpu_coregroup_mask(cpu); > +#endif > +#ifdef CONFIG_SCHED_CLUSTER > + core_mask = cpu_clustergroup_mask(cpu); > +#endif See, same here. This is a mess and unmaintainable. thanks, greg k-h