Received: by 2002:a05:6a10:206:0:0:0:0 with SMTP id 6csp304161pxj; Thu, 3 Jun 2021 07:09:09 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwPeLpy1rznPMEZ3cKRdDf4HcYqp+3eL4ngoJZez1HSP1GJnvgPTqKKaagaFbIZVg627YAm X-Received: by 2002:a17:906:3057:: with SMTP id d23mr30926358ejd.131.1622729348921; Thu, 03 Jun 2021 07:09:08 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1622729348; cv=none; d=google.com; s=arc-20160816; b=DShbm4PG3U3cVzcKRCnbxjV6PqBN+KZ+P2E2loy7HgSE9AycrwEmWW4twq/2eBYUlY JvonI08u+g0XU4aVpByr0k40CefYLdqGP7bNwFd9o8xlKGh9L3Wb4FspdI/hhCZAEc32 u2ukSNU3TSvOe5v+PNjV7Ul0Rs+ja71nMYGGimp8VUA6C60K6nMHoHmRsmSsGsgo+X1P B0wyUb/wOd8xykmpqUoLZtRVrglncIJuQVQxfSTd8vRoe2GMjimBMaRS74EJULA1s4XW yRp5zS8VuG3HvvbWkKee6RWi+kmhvXlkJ7rXV3oiU0G5gPTxynMgX1xj/In2dWbT9BlC k0Lw== 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=BdUT7fSQxE+pFuptfOuKo/ziVfKaaaMJ8N8FBXTQWVM=; b=vmISE9g9VUKEv2Pa7S3mM1ta//vGqxBfizZx1Ws4XXt1/S6tawSzn0+8TKniPh1Z37 oMFIVAdc5Uri3ARI+PtfMTeZFcHnRq1VCweo0gN9U+Qk0/4APux4qvjIBUh0SE+8t9cu /mNseC7sCOuQUYlrih6NdWtttQFnKjG4sl/B0bhaJun1ZXcrdWtTGm3nC6eNvG7L8d/g q+h2HCKQmrPuV7d3erOyB3wLXFoIKirX/c7YepEr6P8TTqAhEgJ8Lt80E5GXg+LHLBlp YMgMlv2fxxaL8PVnfNHBn85K5N2EKTgHhqodW7bvfY67/keCqMa7mrO9UsP/hekcZ3pE JIbg== 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 lh4si2361601ejb.152.2021.06.03.07.08.46; Thu, 03 Jun 2021 07:09:08 -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 S231382AbhFCOIi (ORCPT + 99 others); Thu, 3 Jun 2021 10:08:38 -0400 Received: from foss.arm.com ([217.140.110.172]:42256 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229744AbhFCOIh (ORCPT ); Thu, 3 Jun 2021 10:08: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 A4FE712FC; Thu, 3 Jun 2021 07:06:52 -0700 (PDT) Received: from e120325.arm.com (unknown [10.57.85.170]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPA id 624023F73D; Thu, 3 Jun 2021 07:06:50 -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 v7 1/3] sched/core: Introduce SD_ASYM_CPUCAPACITY_FULL sched_domain flag Date: Thu, 3 Jun 2021 15:06:25 +0100 Message-Id: <20210603140627.8409-2-beata.michalska@arm.com> In-Reply-To: <20210603140627.8409-1-beata.michalska@arm.com> References: <20210603140627.8409-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 Reviewed-by: Dietmar Eggemann --- 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