Received: by 2002:a05:6a10:206:0:0:0:0 with SMTP id 6csp3290473pxj; Mon, 24 May 2021 03:17:38 -0700 (PDT) X-Google-Smtp-Source: ABdhPJy6kzYvwSEZcj2NXvgNTB6VTfY6gmg/mrA8+u2GygvsQIjxc6t3kDLHRjoZ+yWztmQ4mm15 X-Received: by 2002:a6b:b48a:: with SMTP id d132mr15679983iof.167.1621851458650; Mon, 24 May 2021 03:17:38 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1621851458; cv=none; d=google.com; s=arc-20160816; b=LsvdSv43Lhijzt2Hgm+5EvDMYbCzSSGdVvRgGCpBHxZgy1A7t/UjnqQ2csOfAPqOKL Mr3T2n67ZJMxPWRe2TMSQUr0ugiBGwH4kTIF43pI01F1Ovs9S8pKxkpQGlN4v6ygRic/ U12IRvBpfS2P75HMe/ehHOOfBYp3QlHliwcWLx2Sv6JgYJH5Ny1M2blEG+NVyuVegp1g ZRjzVGVYc+/wjv9T8EaSbb6M1lU/751KXDjySfMcZZnXgx8OsvXLGWS3uzicHH5iYFQZ DDyYLMpdOyiifEGOswUT4toC8RF+Qz/3dHW0N8VXHDT/xbRz6p10VN5UXwjw6VHzTIev rFCQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:references:in-reply-to:message-id:date:subject :cc:to:from; bh=UXC43ISoy+LCmUeS1vP2U03FJOuIZq9gA+dH6HA4K3g=; b=pwadh+k+3isZcCWrr7aK5TZZNSn4iJEEsCLKcMyt1l/OzIWfvmfbsq0xTRRTPDGkva 1m2kLdd5hYQZwKFTGaKTNbxx1dtXz3lDYoQHvywUivc1LAcecZJTA1g3ZQ3Y/164DYA3 NEHsxLa05fMm2GaLt6ZDzIZqqIu3rQditDrmkCQ3M/INrWIM5wLXMG3ckpLwFfRhgBgO hO77A6Mv9zslakBhgiTN73OvjLXaCsKFPsIBEHE7N/YVmPRZb03P27hZkdFrA370wzNC MrJVoqVQ7Cj7gERA4a1dlNIb4dlmiqMnsGM2AAo/vKCS+0I+dzY2ulzl7hHfGbLkm3aS vCMA== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=arm.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id x7si12618375ior.77.2021.05.24.03.17.24; Mon, 24 May 2021 03:17:38 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=arm.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232547AbhEXKSP (ORCPT + 99 others); Mon, 24 May 2021 06:18:15 -0400 Received: from foss.arm.com ([217.140.110.172]:40514 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232433AbhEXKSO (ORCPT ); Mon, 24 May 2021 06:18:14 -0400 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id E9CE0113E; Mon, 24 May 2021 03:16:46 -0700 (PDT) Received: from e120325.arm.com (unknown [10.57.84.138]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPA id 6EF673F719; Mon, 24 May 2021 03:16:45 -0700 (PDT) From: Beata Michalska To: linux-kernel@vger.kernel.org Cc: peterz@infradead.org, mingo@redhat.com, juri.lelli@redhat.com, vincent.guittot@linaro.org, valentin.schneider@arm.com, dietmar.eggemann@arm.com, corbet@lwn.net, rdunlap@infradead.org, linux-doc@vger.kernel.org Subject: [PATCH v5 1/3] sched/core: Introduce SD_ASYM_CPUCAPACITY_FULL sched_domain flag Date: Mon, 24 May 2021 11:16:15 +0100 Message-Id: <20210524101617.8965-2-beata.michalska@arm.com> In-Reply-To: <20210524101617.8965-1-beata.michalska@arm.com> References: <20210524101617.8965-1-beata.michalska@arm.com> Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Introducing new, complementary to SD_ASYM_CPUCAPACITY, sched_domain topology flag, to distinguish between shed_domains where any CPU capacity asymmetry is detected (SD_ASYM_CPUCAPACITY) and ones where a full set of CPU capacities is visible to all domain members (SD_ASYM_CPUCAPACITY_FULL). With the distinction between full and partial CPU capacity asymmetry, brought in by the newly introduced flag, the scope of the original SD_ASYM_CPUCAPACITY flag gets shifted, still maintaining the existing behaviour when one is detected on a given sched domain, allowing misfit migrations within sched domains that do not observe full range of CPU capacities but still do have members with different capacity values. It loses though it's meaning when it comes to the lowest CPU asymmetry sched_domain level per-cpu pointer, which is to be now denoted by SD_ASYM_CPUCAPACITY_FULL flag. Signed-off-by: Beata Michalska Reviewed-by: Valentin Schneider --- include/linux/sched/sd_flags.h | 10 ++++++++++ 1 file changed, 10 insertions(+) diff --git a/include/linux/sched/sd_flags.h b/include/linux/sched/sd_flags.h index 34b21e971d77..57bde66d95f7 100644 --- a/include/linux/sched/sd_flags.h +++ b/include/linux/sched/sd_flags.h @@ -90,6 +90,16 @@ SD_FLAG(SD_WAKE_AFFINE, SDF_SHARED_CHILD) */ SD_FLAG(SD_ASYM_CPUCAPACITY, SDF_SHARED_PARENT | SDF_NEEDS_GROUPS) +/* + * Domain members have different CPU capacities spanning all unique CPU + * capacity values. + * + * SHARED_PARENT: Set from the topmost domain down to the first domain where + * all available CPU capacities are visible + * NEEDS_GROUPS: Per-CPU capacity is asymmetric between groups. + */ +SD_FLAG(SD_ASYM_CPUCAPACITY_FULL, SDF_SHARED_PARENT | SDF_NEEDS_GROUPS) + /* * Domain members share CPU capacity (i.e. SMT) * -- 2.17.1