From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by smtp.subspace.kernel.org (Postfix) with ESMTP id 6F86C3C73E9 for ; Wed, 1 Apr 2026 09:30:59 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=217.140.110.172 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1775035861; cv=none; b=E7kpUz12v2JO8clY2i8dssmf0VsZrNG2yQEOELcwZ7JHEi7/BRlh6gae1xK5zABeF2EsouXX9Pa5GnQtEsYoYkoztN/c6XiaQkuC7OM8rvC6EKwSjFAJ/Zz4hl5OZMVvtpqIDp2cgrTeAIIVMJcVPaz5ksJckpKL+NYqHX9QZiA= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1775035861; c=relaxed/simple; bh=H83Od+u3C5sW9Damb8YJ3hUuqJzxsZbQqVCIepl/uhE=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=hCTVppt2EOhtv0Wzc/4TCPXdDkZKLafHbwgtNPbDePriNLzxyq/GygXKKdgCbLRkTNhLab6wAzZARoQ6xoH937alp3Rr9TzqOdAlTPUJbjA6w5L1DMBUXNW4hF/ofEaBGMpOjNMXk3dkiDbeJLMKrG9lOABufuTB66Fj+Hby6wI= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=arm.com; spf=pass smtp.mailfrom=arm.com; dkim=pass (1024-bit key) header.d=arm.com header.i=@arm.com header.b=OF7Q1BNz; arc=none smtp.client-ip=217.140.110.172 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=arm.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=arm.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=arm.com header.i=@arm.com header.b="OF7Q1BNz" 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 C21D01570; Wed, 1 Apr 2026 02:30:52 -0700 (PDT) Received: from [10.1.28.49] (e127648.arm.com [10.1.28.49]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id A777D3F7D8; Wed, 1 Apr 2026 02:30:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=arm.com; s=foss; t=1775035858; bh=H83Od+u3C5sW9Damb8YJ3hUuqJzxsZbQqVCIepl/uhE=; h=Date:Subject:To:Cc:References:From:In-Reply-To:From; b=OF7Q1BNzL9auBxzLhtQ1Gijw6n3YyfCVHzUaxZVx+67HkVRr+Qw3Vb/zWgXWb0szo 0qi9/91jwpjEzZwGqZF1mauZpFQ/Uy+3mufexJnRuyIdktBFxz8nRVDAzRDUaXdqpQ BpNGXTr5+isdaFgMIIhUP9D0zzV05J/uOoNahM2g= Message-ID: Date: Wed, 1 Apr 2026 10:30:53 +0100 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH RESEND 2/4] sched/fair: Ignore misfit load if the destination CPU cannot help To: Ricardo Neri , Ingo Molnar , Peter Zijlstra , Juri Lelli , Vincent Guittot , Dietmar Eggemann , Steven Rostedt , Ben Segall , Mel Gorman , Valentin Schneider , Tim C Chen , Barry Song Cc: "Rafael J. Wysocki" , Len Brown , ricardo.neri@intel.com, linux-kernel@vger.kernel.org References: <20260330-rneri-fix-cas-clusters-v1-0-1e465b6fecb2@linux.intel.com> <20260330-rneri-fix-cas-clusters-v1-2-1e465b6fecb2@linux.intel.com> Content-Language: en-US From: Christian Loehle In-Reply-To: <20260330-rneri-fix-cas-clusters-v1-2-1e465b6fecb2@linux.intel.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 3/30/26 23:20, Ricardo Neri wrote: > There is no point in identifying scheduling groups with misfit tasks if the > destination CPU cannot help (i.e., it has less than 20% greater capacity > than the most performant CPU in the group). There's a mismatch here because capacity_greater() is 5%? You could use 20% fits fits_capacity() I'd say it's too strict here. > > Since migrating misfit tasks takes precedence over relieving fully_busy > groups, identifying a group with misfit tasks causes a destination CPU of > smaller maximum capacity to back off (see capacity checks in update_sd_ > pick_busiest()) even if it can help: it could help a group of equally small > maximum capacity if classified as fully_busy or has_spare. > > The described situation can happen if a scheduling domain has groups of > big CPUs alongside two or more clusters of smaller CPUs that share L2 > cache. Load should be balanced between these sets of smaller CPUs when > CONFIG_SCHED_CLUSTER is enabled. > > Signed-off-by: Ricardo Neri > --- > kernel/sched/fair.c | 4 +++- > 1 file changed, 3 insertions(+), 1 deletion(-) > > diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c > index 9da5014f8387..3c50ecffa4c7 100644 > --- a/kernel/sched/fair.c > +++ b/kernel/sched/fair.c > @@ -10302,7 +10302,9 @@ static inline void update_sg_lb_stats(struct lb_env *env, > if (local_group) > continue; > > - if (sd_flags & SD_ASYM_CPUCAPACITY) { > + /* Only look for misfit load if dst_cpu can help */ > + if (sd_flags & SD_ASYM_CPUCAPACITY && > + capacity_greater(capacity_of(env->dst_cpu), group->sgc->max_capacity)) { > /* Check for a misfit task on the cpu */ > if (sgs->group_misfit_task_load < rq->misfit_task_load) { > sgs->group_misfit_task_load = rq->misfit_task_load; > Apart from the above nit: Reviewed-by: Christian Loehle