Received: by 2002:a05:6a10:206:0:0:0:0 with SMTP id 6csp3290673pxj; Mon, 24 May 2021 03:18:01 -0700 (PDT) X-Google-Smtp-Source: ABdhPJyaDMbxOR5pLeOqpJ4nPfCsLWlxxKtx+w9tljeVEb82NsmxkgVLSxDAJrN5x2fN91veydTy X-Received: by 2002:aa7:c0c8:: with SMTP id j8mr12520973edp.4.1621851480936; Mon, 24 May 2021 03:18:00 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1621851480; cv=none; d=google.com; s=arc-20160816; b=cc44R5KK6fdIntL4ZqpRUmJpAF3o39gYMVCzvrgOJO7EYZOtm0dY8VsZY6ruiuGjLa ashXu4VfWK65TWnAlEGf9byQ3AMIy9HkagUluPE4nhZJj2ZoiBQX8owmyVrORSub4L6o PPcsf6uBjLb1wgJ9LM/+KVj1xlQOp6vHRvMwdH/ohLsEJHdc5H7VD2LR/9hN3Vn6oD/t qi66/Knbawtxq2vD4SSHAhj437+0Qt8EHVBfxS/n9X+rBIrmuH952l6cHTjOVoJEqHeF SJJZcqxuwFiqDeuj7oAC2fF5KVQrJ7d9PkbHL+vMNTjwwLjtNmVqe/jlHPCAv6ZIXEWH iURA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:message-id:date:subject:cc:to:from; bh=w6hLT7bW8eAHUs4t+eyGxkBaxSzWHy8+0C9vnrgc5cA=; b=iiGln6KxqVAQlSjdXRRcq9PxaG9B3bg2wG1wdMWA4X6y/NNMXXCRqhJtgXcfLCwKpY QyGoTWO1fjr2Z+zeBPVsOHp5HeGRm+MwONK5cMk79Js4RWbyMxF/xRoGMKxV1ePxNgAa xlFcEaZw08sKY3RAmL2UZ1EdaTeri/tP6kM1R7KdRhVbqZXIzfrq9P5cj9wNGvvIvdYX iCBInVNqzRUzJLMw/NaPE02G1llaAOxcF0r8E0h/j8pW1FNN3LDsOQkEdaATrNNq77Gj wTsPLc1Ol/2ou0YDh0pgfpP+S1lnx++y/rWLi9LEXujmXBO/0YEFBSE7p9OCjUrBB7Ub B8pw== 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 nd5si10075843ejc.395.2021.05.24.03.17.37; Mon, 24 May 2021 03:18:00 -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 S232513AbhEXKSG (ORCPT + 99 others); Mon, 24 May 2021 06:18:06 -0400 Received: from foss.arm.com ([217.140.110.172]:40504 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232433AbhEXKSF (ORCPT ); Mon, 24 May 2021 06:18:05 -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 1124431B; Mon, 24 May 2021 03:16:37 -0700 (PDT) Received: from e120325.arm.com (unknown [10.57.84.138]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPA id 8B9263F719; Mon, 24 May 2021 03:16:35 -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 0/3] Rework CPU capacity asymmetry detection Date: Mon, 24 May 2021 11:16:14 +0100 Message-Id: <20210524101617.8965-1-beata.michalska@arm.com> Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org As of now, the asym_cpu_capacity_level will try to locate the lowest topology level where the highest available CPU capacity is being visible to all CPUs. This works perfectly fine for most of existing asymmetric designs out there, though for some possible and completely valid setups, combining different cpu microarchitectures within clusters, this might not be the best approach, resulting in pointing at a level, at which some of the domains might not see any asymmetry at all. This could be problematic for misfit migration and/or energy aware placement. And as such, for affected platforms it might result in custom changes to wake-up and CPU selection paths. As mentioned in the previous version, based on the available sources out there, one of the potentially affected (by original approach) platforms might be Exynos 9820/990 with it's 'sliced' LLC(SLC) divided between the two custom (big) cores and the remaining A75/A55 cores, which seems to be reflected in the made available dt entries for those platforms. The following patches rework how the asymmetric detection is being carried out, allowing pinning the asymmetric topology level to the lowest one, where full range of CPU capacities is visible to all CPUs within given sched domain. The asym_cpu_capacity_level will also keep track of those levels where any scope of asymmetry is being observed, to denote corresponding sched domains with the SD_ASYM_CPUCAPACITY flag and to enable misfit migration for those. In order to distinguish the sched domains with partial vs full range of CPU capacity asymmetry, new sched domain flag has been introduced: SD_ASYM_CPUCAPACITY_FULL. The overall idea of changing the asymmetry detection has been suggested by Valentin Schneider Verified on (mostly): - QEMU (version 4.2.1) with variants of possible asymmetric topologies - machine: virt - modifying the device-tree 'cpus' node for virt machine: qemu-system-aarch64 -kernel $KERNEL_IMG -drive format=qcow2,file=$IMAGE -append 'root=/dev/vda earlycon console=ttyAMA0 sched_debug sched_verbose loglevel=15 kmemleak=on' -m 2G --nographic -cpu cortex-a57 -machine virt -smp cores=8 -machine dumpdtb=$CUSTOM_DTB.dtb $KERNEL_PATH/scripts/dtc/dtc -I dtb -O dts $CUSTOM_DTB.dts > $CUSTOM_DTB.dtb (modify the dts) $KERNEL_PATH/scripts/dtc/dtc -I dts -O dtb $CUSTOM_DTB.dts > $CUSTOM_DTB.dtb qemu-system-aarch64 -kernel $KERNEL_IMG -drive format=qcow2,file=$IMAGE -append 'root=/dev/vda earlycon console=ttyAMA0 sched_debug sched_verbose loglevel=15 kmemleak=on' -m 2G --nographic -cpu cortex-a57 -machine virt -smp cores=8 -machine dtb=$CUSTOM_DTB.dtb v5: - building CPUs list based on their capacity now triggered upon init and explicit request from arch specific code to rebuild sched domains - detecting asymmetry scope now done directly in sd_init v4: - Based on Peter's idea, reworking asym detection to use per-cpu capacity list to serve as base for determining the asym scope v3: - Additional style/doc fixes v2: - Fixed style issues - Reworked accessing the cached topology data as suggested by Valentin Beata Michalska (3): sched/core: Introduce SD_ASYM_CPUCAPACITY_FULL sched_domain flag sched/topology: Rework CPU capacity asymmetry detection sched/doc: Update the CPU capacity asymmetry bits Documentation/scheduler/sched-capacity.rst | 6 +- Documentation/scheduler/sched-energy.rst | 2 +- include/linux/sched/sd_flags.h | 10 ++ kernel/sched/topology.c | 194 +++++++++++++-------- 4 files changed, 133 insertions(+), 79 deletions(-) -- 2.17.1