Received: by 2002:a05:6a10:206:0:0:0:0 with SMTP id 6csp745083pxj; Thu, 27 May 2021 10:36:25 -0700 (PDT) X-Google-Smtp-Source: ABdhPJzFqQ6WZ0OHAg25Ujlt8BxXg3DpuBYlqCVN2cv9u3uOfRjv7En5VfV1yOjQhhiow4kMkxLv X-Received: by 2002:a17:906:e08a:: with SMTP id gh10mr4994328ejb.533.1622136984981; Thu, 27 May 2021 10:36:24 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1622136984; cv=none; d=google.com; s=arc-20160816; b=F/WjEtryqLdMgptBdDe5t82x6BYrUcOX22AXJb71lX+rYLqF/fsP3+gFPuY1Xmm5TU yKmHRj9PfeHxY8PUTDQVGdvmunPibUjjghFA0W35V7+BkTo2xKamfE6umTpfn7EUr6rw pysiW7ldt0dj9SDn29nwMZ4aHLQRCPddBn2b4zXo4A93d3lkbWh6/LpI0C6m1Gue9FBp FthaKysSM0j2IZeJlAkF0JoTr3SZeXkul2o0lq20u/+UBJJSIbQl+3XoWBWoMZpMZmdh oscxDxogLBGu9T+arKC+isLAwEqj3TyNePh9XKg0mbBi+tkojKyFOVly6akF7BE3EA3s owXA== 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=Hru+6ICfLgbjz7LmlptuLLe2pruQRw4lr11Rd5l8QNPi14LpKxx75MibkVuDzsY8YU MwHh6HnNASSDGbHvuPdoQ/a2yiLSDLedbXIWv61ybn7cidoWGj40tW9IgmyyjSs0e28S mG15veEWBEhYIvdAozBU0vvPFuyvtQGC27qqCBaa8nT4GVot59OL9dbqN3ovN2/TMkrm hkAZm6gTSNd/dmD6olmGiwpB2GkwbsEi17pv4qKEBrwHUTzCPMk1GnSieXsLz8U6HHck qarcAusovXOhNqXmxM+6VKUHzCcWXq3JZdkfPT95jUh4zZE0/NBc2lHTSCgcPH4e8XeS WplQ== 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 bx27si2632160edb.216.2021.05.27.10.36.01; Thu, 27 May 2021 10:36:24 -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 S234399AbhE0Pkn (ORCPT + 99 others); Thu, 27 May 2021 11:40:43 -0400 Received: from foss.arm.com ([217.140.110.172]:59500 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S234149AbhE0Pkh (ORCPT ); Thu, 27 May 2021 11:40:37 -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 E0B2111D4; Thu, 27 May 2021 08:39:03 -0700 (PDT) Received: from e120325.arm.com (unknown [10.57.84.138]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPA id 656633F73B; Thu, 27 May 2021 08:39:02 -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 v6 1/3] sched/core: Introduce SD_ASYM_CPUCAPACITY_FULL sched_domain flag Date: Thu, 27 May 2021 16:38:40 +0100 Message-Id: <20210527153842.17567-2-beata.michalska@arm.com> In-Reply-To: <20210527153842.17567-1-beata.michalska@arm.com> References: <20210527153842.17567-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