Received: by 2002:a05:6a10:a841:0:0:0:0 with SMTP id d1csp204646pxy; Wed, 28 Apr 2021 02:34:24 -0700 (PDT) X-Google-Smtp-Source: ABdhPJymjlG9J8lfmtKkO5sb4fcgh2sNdScpYsyk4QnuuZW/CIBxXHiRtZsMrQHQz9aIBBLw1y/p X-Received: by 2002:aa7:d787:: with SMTP id s7mr9846308edq.240.1619602463804; Wed, 28 Apr 2021 02:34:23 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1619602463; cv=none; d=google.com; s=arc-20160816; b=TuEiKy7TP+LJYkZL8youHcglUS7YL/UKVz+AggcXf7gnwt+Sfufgs9Tx70Flu8j1z+ GpoMHLOUuoK5DumFjoXgTBYl8tLea9qNzFQSwli6y9zX5NMN6+tekiPAG3Vael6JDDK3 4VGMR3FcaSbCkv6Egp0Lxz+kdaZkOtUO9UG2Bdz04HHwvUvdrEHbgjNOS9aRQrj68zxI MViTNBGnqinzLDnQJLhaoX2z1l0y/mHVH9UO55IaCspXh+K7D/5J1EtWhl+hG0OCkf8/ tx0kQxeEbKczRK2qTH1Bz6xnn7WLeNwLIgMErGdIeR1EZzrEJyJQA+6p0YBtvwfPIxY9 0a3Q== 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=16/ofYKAVBFC9z8nY5fWT7eBFd6xV7upLOkGYRYrPsk=; b=Q1Yw4N0quy8VFCe1BUb3KRb1Gv+FcLcSl4gtwSWEVeFsZOEz1WjbeEG2OZbOB2+Dct LYMWvPznbW0njaleBcFS4MhKEayN9zYJq/T3eomfHZAu1d7weWlXTN7bbHB6Y8FAKC5g T8LTqyf8+QOEF4HMuZXt1zJ05JPtQn0CtOoqibt1ZDvGvKnmy29WGWCDQ7aplmu+zE/f 5uYrON0lRB+ekMqMqcb4jDVjlNclCRSLYQELAoXYGwXFCwcBqR7EWLXdTyMfKGKx6zKj Ll2GiHjChEIqQBDOixpwFDGXYCTvt0ZhQM2nnmZDLTIHNNQmVAF0SJkl71U12/dljq42 Jw4A== 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 z26si2799434ejc.46.2021.04.28.02.33.59; Wed, 28 Apr 2021 02:34:23 -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 S238245AbhD1Jds (ORCPT + 99 others); Wed, 28 Apr 2021 05:33:48 -0400 Received: from foss.arm.com ([217.140.110.172]:37988 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S238222AbhD1Jds (ORCPT ); Wed, 28 Apr 2021 05:33:48 -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 7E9BC1042; Wed, 28 Apr 2021 02:33:03 -0700 (PDT) Received: from e113131-lin.cambridge.arm.com (e113131-lin.cambridge.arm.com [10.1.195.76]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPA id 464213F70D; Wed, 28 Apr 2021 02:33: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, linux-doc@vger.kernel.org Subject: [RFC PATCH v2 1/3] sched/core: Introduce SD_ASYM_CPUCAPACITY_FULL sched_domain flag Date: Wed, 28 Apr 2021 10:32:41 +0100 Message-Id: <1619602363-1305-2-git-send-email-beata.michalska@arm.com> In-Reply-To: <1619602363-1305-1-git-send-email-beata.michalska@arm.com> References: <1619602363-1305-1-git-send-email-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 range 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 --- 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 34b21e9..57bde66 100644 --- a/include/linux/sched/sd_flags.h +++ b/include/linux/sched/sd_flags.h @@ -91,6 +91,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) * * SHARED_CHILD: Set from the base domain up until spanned CPUs no longer share -- 2.7.4