Received: by 2002:a05:6a10:206:0:0:0:0 with SMTP id 6csp2626438pxj; Mon, 17 May 2021 06:11:27 -0700 (PDT) X-Google-Smtp-Source: ABdhPJzwzHrsoZuvVD1KcAZ0CkDutvca3B2TGMbywOMkrp5kPp+vGmsXNFO7MjgBcJ2gGtXVEc/B X-Received: by 2002:a05:6402:31a7:: with SMTP id dj7mr71269177edb.314.1621257087576; Mon, 17 May 2021 06:11:27 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1621257087; cv=none; d=google.com; s=arc-20160816; b=VO4n/822M7iCqN8CTbhUrgDdCG59LUND73dwA6l64ZyP8MKyrQIt4LBqvZwvi+IQ0k pdIqya6RYbgbdPFnCfOMSC5OQJnEnpiBgD1vzUbBRe+ptp8RMivn0EBDnAUP/iJUB8U7 Smoj96HuhGQc+0/5DZgBrW7Gvqk+Yexbr74/nl+TAmVGDrwAVxCT4X3AYCV7mMnbRjeY QJ3UC22PYWPNSz9vALCUvj6ZEZSEVSxH5ab/cJZYZUSnMMssmGCs/B+B2IvE19sZaLph ovoeisIwdxfKnJ8r5yg74w6A7mXQQqhQNU/4/hB7E/waRpWSwncqG8QMhiV+NB6Xe1n9 P7YA== 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=roTKSqNfo3X6R/BB8pzdaCbupWEI2I1G6IrY9CwNWsI=; b=zlfQ64iq2V1qMPbNN2DQ6Xxxtu025SFhn0XuD7ak4/IsBlXByxCLLmBsTohpwVh2Oa h7UDdhUQwa17VkN2ZRlayzqhFD1yzHVdu6iRXM1UHq2C3Bij/g3mNtylleU1FIa09fTF e8MBIp6LU8qPwdvMn41T23vQ24a8YM+yav+iItOZHl17QUxaA/NYffgfB7wd9zurn4uB uzexJwSCF+RaooOkpyMffc5cRzJ4egb7CypV9Ng1SX/erYsCNIwsl2VCH0xacAKt/ZrJ dt4ctjA9fXcVK2Vw7+/qbx9v6y4W9NOXxT3IFyHs5WW8gdN8SkxDdIoNFbhC9/xk3fCO 2Ayg== 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 c7si13633031eds.391.2021.05.17.06.11.04; Mon, 17 May 2021 06:11:27 -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 S235542AbhEQIZu (ORCPT + 99 others); Mon, 17 May 2021 04:25:50 -0400 Received: from foss.arm.com ([217.140.110.172]:45166 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230507AbhEQIZs (ORCPT ); Mon, 17 May 2021 04:25: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 40386106F; Mon, 17 May 2021 01:24:32 -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 E3CE43F719; Mon, 17 May 2021 01:24:30 -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 v4 1/3] sched/core: Introduce SD_ASYM_CPUCAPACITY_FULL sched_domain flag Date: Mon, 17 May 2021 09:23:49 +0100 Message-Id: <1621239831-5870-2-git-send-email-beata.michalska@arm.com> In-Reply-To: <1621239831-5870-1-git-send-email-beata.michalska@arm.com> References: <1621239831-5870-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 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 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