Received: by 2002:a05:6a10:9848:0:0:0:0 with SMTP id x8csp749648pxf; Thu, 1 Apr 2021 12:32:14 -0700 (PDT) X-Google-Smtp-Source: ABdhPJzEoRo40vtFimNh25weV7kACTinUmLJBo94+7IetZ6UKCSFJpdoR7vV443TUC8jqV7/dGI4 X-Received: by 2002:a5e:8712:: with SMTP id y18mr7862753ioj.65.1617305533914; Thu, 01 Apr 2021 12:32:13 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1617305533; cv=none; d=google.com; s=arc-20160816; b=ZGeBXIO59+/GQAJ4jE1pC4Fmr2zWBPkENnvGFLX59Qlw3T5jvZfhfGuSw7dFkPvgYk kh30+RRfteVzeIbcgGW42onFzYF+lUdpyY6n+6uxDwlAhSwF6DrjKr4FrvjjLltGd5Vu fPvJ28BxOdRIBl5wZksQlGQY9Z24/BJjGF6Ao1jCQVDKD7CiiBgRTD7erYjilzi9kblb Xup6/HYdf9d9TpDQokJKJqulhM9ZaG9TcdRys1BMPU/pkI9Xr4/ubiBOfeclhPioOoLl HOmfJHtru5mJVvoi9MJQo4D7fPUEk3U1Oer6DumZOEGF3yf1ex6GEkJVufVbxFObwVtm qI8A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :message-id:date:subject:cc:to:from; bh=xF23v3hQNWnIZsm21OKKBn6fK9csglaURQjk1E2ODU8=; b=mgdQKy1oE7yOlS8gUQoiYXhrQIPQ6KN0cerkiegWmtagh5e/SUEv8BZx9N6x0FbCbx USCmR134ddT5iJaUKR2dxxRUecj0VXEuWp0NtSd+C6smGUtDH89CxekhfH6PHO3yWs4d +bnJhRkKrNGVZlQY2X9YkmvvNWj0iC4i5pS2ZbovVzWDLomhfUlM4Gk3RxchJTtMRYUS H6lqp9LYvqdwmhT5DsBt6XbQzut505nxGIjZkGSRGPoq8ynJ6+Vi3V0V1j+puh6OS8vK Bh/9wyH3/YRej5DUJok3Ihc1a3npeBbBtLP7gbHEv+quFNK+tLMzP7M7K1cS9mD/6yUJ bqng== 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 z8si5142565jat.80.2021.04.01.12.31.59; Thu, 01 Apr 2021 12:32:13 -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 S234601AbhDATa1 (ORCPT + 99 others); Thu, 1 Apr 2021 15:30:27 -0400 Received: from foss.arm.com ([217.140.110.172]:48166 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231550AbhDATaY (ORCPT ); Thu, 1 Apr 2021 15:30:24 -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 C40F0D6E; Thu, 1 Apr 2021 12:30:24 -0700 (PDT) Received: from e113632-lin.cambridge.arm.com (e113632-lin.cambridge.arm.com [10.1.194.46]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPA id 3B1943F719; Thu, 1 Apr 2021 12:30:23 -0700 (PDT) From: Valentin Schneider To: linux-kernel@vger.kernel.org Cc: Peter Zijlstra , Ingo Molnar , Vincent Guittot , Dietmar Eggemann , Morten Rasmussen , Qais Yousef , Quentin Perret , Pavan Kondeti , Rik van Riel , Lingutla Chandrasekhar Subject: [PATCH v4 0/3] sched/fair: load-balance vs capacity margins Date: Thu, 1 Apr 2021 20:30:03 +0100 Message-Id: <20210401193006.3392788-1-valentin.schneider@arm.com> X-Mailer: git-send-email 2.25.1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi folks, I split up the extra misfit patches from v3 as I'm still playing around with those following Vincent's comments. In the meantime, I believe the first few patches of the series can still be considered as standalone. o Patch 1 prevents pcpu kworkers from causing group_imbalanced o Patch 2 is an independent active balance cleanup o Patch 3 introduces yet another margin for capacity to capacity comparisons The "important" one is patch 3, as it solves misfit migration issues on newer platforms. This is based on top of today's tip/sched/core at: 0a2b65c03e9b ("sched/topology: Remove redundant cpumask_and() in init_overlap_sched_group()") Testing ======= I ran my usual [1] misfit tests on o TC2 o Juno o HiKey960 o Dragonboard845C o RB5 RB5 has a similar topology to Pixel4 and highlights the problem of having two different CPU capacity values above 819 (in this case 871 and 1024): without these patches, CPU hogs (i.e. misfit tasks) running on the "medium" CPUs will never be upmigrated to a "big" via misfit balance. The 0day bot reported [3] the first patch causes a ~14% regression on its stress-ng.vm-segv testcase. I ran that testcase on: o Ampere eMAG (arm64, 32 cores) o 2-socket Xeon E5-2690 (x86, 40 cores) and found at worse a -0.3% regression and at best a 2% improvement - I'm getting nowhere near -14%. Revisions ========= v3 -> v4 -------- o Tore out the extra misfit patches o Rewrote patch 1 changelog (Dietmar) o Reused LBF_ACTIVE_BALANCE to ditch LBF_DST_PINNED active balance logic (Dietmar) o Collected Tested-by (Lingutla) o Squashed capacity_greater() introduction and use (Vincent) o Removed sched_asym_cpucapacity() static key proliferation (Vincent) v2 -> v3 -------- o Rebased on top of latest tip/sched/core o Added test results vs stress-ng.vm-segv v1 -> v2 -------- o Collected Reviewed-by o Minor comment and code cleanups o Consolidated static key vs SD flag explanation (Dietmar) Note to Vincent: I didn't measure the impact of adding said static key to load_balance(); I do however believe it is a low hanging fruit. The wrapper keeps things neat and tidy, and is also helpful for documenting the intricacies of the static key status vs the presence of the SD flag in a CPU's sched_domain hierarchy. o Removed v1 patch 4 - root_domain.max_cpu_capacity is absolutely not what I had convinced myself it was. o Squashed capacity margin usage with removal of group_smaller_{min, max}_capacity() (Vincent) o Replaced v1 patch 7 with Lingutla's can_migrate_task() patch [2] o Rewrote task_hot() modification changelog Links ===== [1]: https://lisa-linux-integrated-system-analysis.readthedocs.io/en/master/kernel_tests.html#lisa.tests.scheduler.misfit.StaggeredFinishes [2]: http://lore.kernel.org/r/20210217120854.1280-1-clingutla@codeaurora.org [3]: http://lore.kernel.org/r/20210223023004.GB25487@xsang-OptiPlex-9020 Cheers, Valentin Lingutla Chandrasekhar (1): sched/fair: Ignore percpu threads for imbalance pulls Valentin Schneider (2): sched/fair: Clean up active balance nr_balance_failed trickery sched/fair: Introduce a CPU capacity comparison helper kernel/sched/fair.c | 68 +++++++++++++++++++-------------------------- 1 file changed, 29 insertions(+), 39 deletions(-) -- 2.25.1