Received: by 2002:a05:6a10:206:0:0:0:0 with SMTP id 6csp745011pxj; Thu, 27 May 2021 10:36:19 -0700 (PDT) X-Google-Smtp-Source: ABdhPJxv+DI8vvVkiqQKE/qn5fBPWc/Uf4cRklapStz1quIMuIuInVNiCZ9APGr2EyDbhP+xvuPv X-Received: by 2002:a05:6402:3512:: with SMTP id b18mr5501435edd.245.1622136979477; Thu, 27 May 2021 10:36:19 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1622136979; cv=none; d=google.com; s=arc-20160816; b=xcS6QZf4MHcbIszVXW1lBBE1MGc0vUFm73dAn4/NK6Ta0bxDiRzfYIPyGPVptX8W44 S7pUltFmtUvR024kPgwC4wDlxodZZ6uekAUDENr179KCre3gUzBJD3IhDf9wf8bmqo1c TqhNs8iD7IN5PgacTZ5GVjm28EEtuoGmLB+0reRBVzgKZjPPEMCvvMusiPppl0Ergm53 mNlG6+ov3cHMeGsERAOt0K4nna6bIPR5mdHGvfY96oR+IiThH07nPMG6n2S7irVpI9pD INqdire4AETiC/I/v+wCcJ4qAKCPbyrt1vxZitKNVq+w3iEgx9IjpTZFGNNkvtz2Oifz yocw== 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=AIHF/CvDxilY11JsgCybZU7lFnz5HqmswmrzrWX0wfI=; b=zmi/ytwtnDBkR0+27V5L0+/vgBRDEnSjEluDbBrrnEKdVQ2sVTdBZhOYjIRDylMOsn CaMHXzpI47ksBP7vvZPrTZQHgkoUo3RARvkIM1MtAPMAfC1uwroTwskFzK6H3x5zgkd8 uzWxaNmoPGiiLn5a6n+rZCtEDosCrYnFHgqBD9KIq4ZYg7e1eqKnAFD1COoM87o4Tcpi 3S+eokglziVcLKh1P/57pksXwQVhSbcB2orgcHibMaaa3PyWqAZ6kK2VU/b1xEbmA0nP 5R5DqtH1vKhm9sOa6lfCh4bpTfKww8W9PCbS9SGdaKPnLjGnRB9FMZ8hBbGzJiuuYfDa cQCQ== 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 t6si2679090edd.419.2021.05.27.10.35.55; Thu, 27 May 2021 10:36:19 -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 S229878AbhE0Pkc (ORCPT + 99 others); Thu, 27 May 2021 11:40:32 -0400 Received: from foss.arm.com ([217.140.110.172]:59486 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229698AbhE0Pkb (ORCPT ); Thu, 27 May 2021 11:40:31 -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 34C5F11D4; Thu, 27 May 2021 08:38:58 -0700 (PDT) Received: from e120325.arm.com (unknown [10.57.84.138]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPA id F1C513F73B; Thu, 27 May 2021 08:38:55 -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 0/3] Rework CPU capacity asymmetry detection Date: Thu, 27 May 2021 16:38:39 +0100 Message-Id: <20210527153842.17567-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 v6: - improving code readability 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