From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-ed1-f48.google.com (mail-ed1-f48.google.com [209.85.208.48]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 663973ED5D6 for ; Mon, 29 Jun 2026 15:35:45 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=pass smtp.client-ip=209.85.208.48 ARC-Seal:i=2; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1782747346; cv=pass; b=Ob15JrOXReYAezBhd0B2KCs1WvVwkZMnxD0PY2jIM3Yh9JJH3YxRLd+IGhs2c0cxIwiI5FvsMYQj0+39cFd2dfHyHuuhGG4pToMPoGRl5FlCpesyQL6FesysuN8qtM8ZFUMIuXklDzjMT/7qxtnOum5FgsQRNh6+bZGy9XwYYEk= ARC-Message-Signature:i=2; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1782747346; c=relaxed/simple; bh=2ikU7aH+WYq4Jltujhc7uG8ruUdNweYL9gLR26vAqo4=; h=MIME-Version:References:In-Reply-To:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=RKvXEzUmWBTLQmLBTZsd9wbAo9nhSnpMhZkJ9OzQOBps2gK8/BIDHPrz/H/i8E0VVks5W6ee8EZTqwfGBJk/3g7F/GFE8ycJAoppYWtnqRU9J7cszUNb4nrhhZ391faU7LNT/QpG/5PjdnydBxb3Q/mfyHMQg4xhzkmhYoSoAzs= ARC-Authentication-Results:i=2; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linaro.org; spf=pass smtp.mailfrom=linaro.org; dkim=pass (2048-bit key) header.d=linaro.org header.i=@linaro.org header.b=tODqpAZk; arc=pass smtp.client-ip=209.85.208.48 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linaro.org Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linaro.org Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=linaro.org header.i=@linaro.org header.b="tODqpAZk" Received: by mail-ed1-f48.google.com with SMTP id 4fb4d7f45d1cf-697ebe536b6so5430751a12.1 for ; Mon, 29 Jun 2026 08:35:45 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1782747344; cv=none; d=google.com; s=arc-20260327; b=WIyDofazrCgO5uw4msDfhFzOy+knioavSGk/jDqfpiuiIOvnCSB/omMmoR41tltbtz D4NbY1XWg5zGmJaagVsk8vW4xiFT+AfcWzQiZF0kCSiD7sNKBCAhBNlz+ped//Yfciog hoBA/iEaS9gOkBcsHCsOhEq8y4J1knxU+79R2H5mHmjPYFItKV6CecEgNW5rCUG4fEPf w1tsDW2DkfCaaOVDGGgTUs5G4gokao7knh6mPLnnvCUKBl2j1Vn5WkGQHCfRkB1YhutS Z9zJEGYu7cwFdEKFYT0GlkS0zUkDiAKx7QaLvtB5e7zyy+shJarvbWevV1CWR/T1rhjk n6uA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20260327; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:dkim-signature; bh=A7ajmKFnI6XCyljK9Y32BVzGeYgBRlUT0n2Hho2zNSA=; fh=n5GFsSHLvWcsnay/XWtD+WNjnsptCVv0Dg+SeuoY7gA=; b=WcocwMelrJ5FZaro5i4aZaMOspg9BD/Hk34lEF9SCENs9Ut6Ca8ZWn1W407LdZWt10 fGJkr9t7pOErjosjFPNAi/O0rwX/3U/H6McSECGthx/5/S+YEcJDnse4DcRY1KiWq7/p DHJb2fItlVdCqaatm2GqGnWGb4z2wQ81KqOIuxRR/DKgA5P7wsmzqASTef4ASjraE8e+ 5KU/iIXfcoiyTxQiPkauKXAej1+UfSrTVdRzqafUHWU/uiT38tSa5DG39Urjw7S6U5Yn BCjjTCnNEU1qUYDCqnPI07HHo9EXaupp/BpWL6Kt3yBkBk8SqQyCicVanyDbACPb7/dQ NZow==; darn=vger.kernel.org ARC-Authentication-Results: i=1; mx.google.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; t=1782747344; x=1783352144; darn=vger.kernel.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=A7ajmKFnI6XCyljK9Y32BVzGeYgBRlUT0n2Hho2zNSA=; b=tODqpAZkTetUHMy5ry6vcG+8BPJysJJlzDbLfkv/vTovw39H0QXeTPks0tnJFnRWKQ cGngdXs6uO4ZWRirtKT48748CIToJLbydup57MrDSafwq1zOB15lE+ONW5I23ZZoIJzC 1fU7GuSPLe/xYqnlkWNIaPOl62JEvvOi7Z0z20PGGW2JGyY0tNXne0th2Hi1yyWL/JFz APeIVY0zho7+/uAJQAzMWYmRiD2W5PqdIiMjRvPt/v639IbtZolrN5UZU/5kflklF/34 zh7i5v/aAInc5jiPESrxO6NbojE7JXUCIQjKtPT1n1sQ8UriD6M/Qwv0F5Avc312yyRp ntgg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1782747344; x=1783352144; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=A7ajmKFnI6XCyljK9Y32BVzGeYgBRlUT0n2Hho2zNSA=; b=V/uCXCNOX6euGWd3/3z4Jh9Q53K6AtsUhXhdbvG2tgK5vnCabir/NuYpXj9FSPB8Nw vHG7SCJj9HfkP9nxAVMZFhKZj+LxoQmlWLKx3yqxqXkfApTrl/1u9xWhf8QnjZmjuZeL 9hQI8hP3uDSdGOfLp2B+6Qj52wXswF00bEV2SGcHri4G02SGr81K4oXxh+runcYwpk9L MPlwwU/rGOC0SI6ZJMlKnmGs+taL8s652EzJCKUnAiQRwdpqrtxUjlFqSCbxN/w4YjvL LRJ4nBVtU1uVb7zWNzpAbzJ4hdGhm2dXbecGwS0LhFM37lKKOrmqg7uZzTxw62Vxpymy Mqng== X-Forwarded-Encrypted: i=1; AHgh+RoHgQB2EuZ++lDxyC+TPqYXeBiJaut/N6DrC8LmIWoU80UPwWDTMjVVifSy4FmhJXMGYPtSlQvW0cNGQnE=@vger.kernel.org X-Gm-Message-State: AOJu0YyDBB6sAjYzHSPriwzXlWs2JIL1Iz1viRt0OrodqUJQhgoC8y9n KanM5e+a1nU6nDxpx/sqzs+Vp5LBwfrx8Q3CJfYZqjUl18ztCXHgMT5MquEmf8NO3wdwo2IjHEA l6EXdjCZv5b4Lr04RsSFl4QPywrMASqYdwKQVaLrf1g== X-Gm-Gg: AfdE7cmQEhISvBcm++Q7uNhYwPicEOnAFBenTP7egQgOj2+fVfMFoHFWtI+NXtIuQj8 OyiKewQCyHxU7Q58wH735R7YdQO5/JnHtvuShO3ULwPsY5zE1oMseg6/sX4QInCIU4FYZji0DN0 rlx3jMb4baBexXiw4h/06DZcaadE3I6e/+cMua/dXLUhrFEO2DWa5cjZTTG22lY85eLGYVKTGZV rUtR0puTYiQUgvr4cP3Z3le8OfTaIHnSAnIECDyEtLiFTffwZ0dJ3ZM3PiyDbaOObiy0xVKv0Wl 7imjeTyOdvgYfWaW26Npvdo8zA== X-Received: by 2002:aa7:d489:0:b0:698:3b7c:be6b with SMTP id 4fb4d7f45d1cf-6983b7cc7acmr3443309a12.39.1782747343741; Mon, 29 Jun 2026 08:35:43 -0700 (PDT) Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 References: <20260622-rneri-fix-cas-clusters-v5-0-19968f2d1497@linux.intel.com> <20260622-rneri-fix-cas-clusters-v5-5-19968f2d1497@linux.intel.com> <20260624052514.GA16859@ranerica-svr.sc.intel.com> <20260626001138.GA19085@ranerica-svr.sc.intel.com> <20260627020253.GA20409@ranerica-svr.sc.intel.com> In-Reply-To: <20260627020253.GA20409@ranerica-svr.sc.intel.com> From: Vincent Guittot Date: Mon, 29 Jun 2026 17:35:31 +0200 X-Gm-Features: AVVi8CfO0KMgEaQCbwPtxg3iczmLO-QZheifHXpMLiFUDLftMNZxllHKVfOxY0Q Message-ID: Subject: Re: [PATCH v5 5/6] sched/fair: Allow load balancing between CPUs of identical capacity To: Ricardo Neri Cc: Christian Loehle , g@ranerica-svr.sc.intel.com, Ingo Molnar , Peter Zijlstra , Juri Lelli , Dietmar Eggemann , Steven Rostedt , Ben Segall , Mel Gorman , Valentin Schneider , Tim C Chen , Chen Yu , K Prateek Nayak , Barry Song , "Rafael J. Wysocki" , Andrea Righi , Len Brown , ricardo.neri@intel.com, linux-kernel@vger.kernel.org Content-Type: text/plain; charset="UTF-8" On Sat, 27 Jun 2026 at 03:53, Ricardo Neri wrote: > > On Fri, Jun 26, 2026 at 04:50:12PM +0200, Vincent Guittot wrote: > > On Fri, 26 Jun 2026 at 02:02, Ricardo Neri > > wrote: > > > > > > On Tue, Jun 23, 2026 at 10:25:14PM -0700, Ricardo Neri wrote: > > > > On Tue, Jun 23, 2026 at 08:45:23AM +0100, Christian Loehle wrote: > > > > > On 6/23/26 08:20, Vincent Guittot wrote: > > > > > > On Tue, 23 Jun 2026 at 01:55, Ricardo Neri > > > > > > wrote: > > > > > >> > > > > > >> sched_balance_find_src_rq() avoids selecting a runqueue with a single > > > > > >> running task as busiest if doing so results in migrating the task to a > > > > > >> CPU with less than ~5% of extra capacity. It also unintentionally > > > > > >> prevents migrations between CPUs of identical capacity. > > > > > >> > > > > > >> When CONFIG_SCHED_CLUSTER is enabled, load should be balanced across > > > > > >> clusters of CPUs with the same capacity. Allowing migration between CPUs > > > > > >> of identical capacity is necessary to meet this goal. > > > > > >> > > > > > >> Use arch_scale_cpu_capacity() to reflect architectural capacity, excluding > > > > > > > > > > > > capacity_of() reflects not only RT and irq pressure but also thermal > > > > > > pressure or system frequency capping. > > > > > > If dst cluster is under thermal mitigation but the source cluster is > > > > > > not, we probably shouldn't spread tasks across both clusters. > > > > > > Have you considered using get_actual_cpu_capacity() instead of > > > > > > arch_scale_cpu_capacity() ? > > > > > > > > > > Replacing arch_scale_cpu_capacity() with get_actual_cpu_capacity() > > > > > would make the == comparison below very unlikely to be true FWIW. > > > > > > > > Yes, this is what I thought too. I did not try with get_actual_cpu_capacity(), > > > > though. Perhaps on Intel processors it would work since rq->avg_hw.load_avg > > > > is not used, IIUC. I am not sure about cpufreq_pressure. I need to check. > > > > > > > > Still, it may work for Intel processors but not for ARM ones. > > > > > > > > > I think it's fine like that, I will prepare a follow-up anyway to make > > > > > it work for our "almost equal capacity" cluster systems and then also > > > > > consider switching to get_actual_cpu_capacity() since we include a margin > > > > > anyway. > > > > > > > > Great! > > > > > > I confirmed that does not use rq->avg_hw.load_avg nor cpufreq_pressure. > > > > I'm not surprised that intel don't use rq->avg_hw.load_avg but I'm > > pretty sure that you use cpufreq_pressure, because any call to > > freq_qos_add_request(..., FREQ_QOS_MAX), like scaling_max_freq, will > > update cpufreq_pressure. > > But in cpufreq_update_pressure() a non-zero pressure can be only computed > if arch_scale_freq_ref() returns non-zero. x86 does not implement this > function. > > The check max_freq <= capped_freq is always true because the default > arch_scale_freq_ref() returns 0. The computed pressure is always 0. Am I > missing something? Yeah, I forgot that Intel has not enabled it. You should consider enable it because of the below > > > > > If one cluster has its max freq capped, you will spread tasks between > > the uncapped and the capped clusters which no longer have the same > > compute capacity. > > I this I agree.