From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from desiato.infradead.org (desiato.infradead.org [90.155.92.199]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 65548215F7D for ; Thu, 19 Feb 2026 14:41:47 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=90.155.92.199 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1771512111; cv=none; b=IlFlYtBWsAv3jW5wMD9UfnOuCI8eX/RYodT3qXvFJRXFHontK2mbhycrJEY67xXv0T31Y0Im5qp+56CdOx0BUMzAcxsB3cMaUzViUjrLEmdrBvJwx4RC+chICwpj7YmAbfQQotJKB9W8viHKEINkFGkpdSDs+uMagQgEFQN67bc= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1771512111; c=relaxed/simple; bh=waDOU1PbfLmanBxZ7GFwL6tRCoNPJ7ESgmAGKiU6ROQ=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=KRYu/z34O22GRy+fN79MbSJjxx4PR20FKiIU2XMAQ5hAF/RJrZI5uQA3ptZLDr2hWexoXN0v+QgcRkduXyWo7IIx5oGwbu6misVEZxZ1zTUFd0tjm7d/1Gui7pUjyHvUTOx19zJKxR/evU0eG3k5BV4ZvbY8pOB0PVCyRGyAFpI= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=infradead.org; spf=none smtp.mailfrom=infradead.org; dkim=pass (2048-bit key) header.d=infradead.org header.i=@infradead.org header.b=aw3MfS1e; arc=none smtp.client-ip=90.155.92.199 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=infradead.org Authentication-Results: smtp.subspace.kernel.org; spf=none smtp.mailfrom=infradead.org Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=infradead.org header.i=@infradead.org header.b="aw3MfS1e" DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=desiato.20200630; h=In-Reply-To:Content-Type:MIME-Version: References:Message-ID:Subject:Cc:To:From:Date:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description; bh=PZCaIXPWX+hpQNgRtyoZ64U5cuTFD0F7+ozxEc46d0g=; b=aw3MfS1enRjCl0+HUyKl5IOnsE cvKZppYM9S2/Q+L617CQmPqFXhxYQ58Q5OOmrK/FrUk0sWXe71P8fJIfRv9OlbtBusNKc2AX4DoDI RmmMBk3YUxB4FMgCAOYg2nAzoJfOkw0wZrl9DVeyLX2psolmQQzMXJNMzWgoIgyMQMng0HzdKMnUG clV+ABAr3lD7ugMXCD3ruCRUW393Y2laFLJVHEZjK6EWEaOFIttSS3eRFf1Dbl3x8ln7Har603etx Sc9I6OVw9uNFK56NV7KHh0DY7feZh2LR1y/74HA5YZr+Wg+UT7V1h1LTWFeuH+S0tI6m9oOLD1XSA 5WaYyxeA==; Received: from 2001-1c00-8d85-5700-266e-96ff-fe07-7dcc.cable.dynamic.v6.ziggo.nl ([2001:1c00:8d85:5700:266e:96ff:fe07:7dcc] helo=noisy.programming.kicks-ass.net) by desiato.infradead.org with esmtpsa (Exim 4.98.2 #2 (Red Hat Linux)) id 1vt5DK-00000001NLE-1QwO; Thu, 19 Feb 2026 14:41:10 +0000 Received: by noisy.programming.kicks-ass.net (Postfix, from userid 1000) id B656630075B; Thu, 19 Feb 2026 15:41:08 +0100 (CET) Date: Thu, 19 Feb 2026 15:41:08 +0100 From: Peter Zijlstra To: Qais Yousef Cc: Tim Chen , Ingo Molnar , K Prateek Nayak , "Gautham R . Shenoy" , Vincent Guittot , Juri Lelli , Dietmar Eggemann , Steven Rostedt , Ben Segall , Mel Gorman , Valentin Schneider , Madadi Vineeth Reddy , Hillf Danton , Shrikanth Hegde , Jianyong Wu , Yangyu Chen , Tingyin Duan , Vern Hao , Vern Hao , Len Brown , Aubrey Li , Zhao Liu , Chen Yu , Chen Yu , Adam Li , Aaron Lu , Tim Chen , Josh Don , Gavin Guo , Libo Chen , linux-kernel@vger.kernel.org Subject: Re: [PATCH v3 00/21] Cache Aware Scheduling Message-ID: <20260219144108.GI1282955@noisy.programming.kicks-ass.net> References: <20260219140828.a7pyzupun7lsdw34@airbuntu> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20260219140828.a7pyzupun7lsdw34@airbuntu> On Thu, Feb 19, 2026 at 02:08:28PM +0000, Qais Yousef wrote: > On 02/10/26 14:18, Tim Chen wrote: > > This patch series introduces infrastructure for cache-aware load > > balancing, with the goal of co-locating tasks that share data within > > the same Last Level Cache (LLC) domain. By improving cache locality, > > the scheduler can reduce cache bouncing and cache misses, ultimately > > improving data access efficiency. The design builds on the initial > > prototype from Peter [1]. > > > > This initial implementation treats threads within the same process as > > entities that are likely to share data. During load balancing, the > > This is a very aggressive assumption. From what I've seen, only few tasks truly > share data. Lumping everything in a process together is an easy way to > classify, but I think we can do better. Not without more information. And that is something we can always add later. But like you well know, it is an uphill battle to get programs to explain/annotate themselves. The alternative is sampling things using the PMU, see which process is trying to access which data, but that too is non-trivial, not to mention it will get people really upset for consuming PMU resources. Starting things with a simple assumption is fine. This can always be extended. Gotta start somewhere and all that. It currently groups things by mm_struct, but it would be fairly straight forward to allow userspace to group tasks manually. > > scheduler attempts to aggregate such threads onto the same LLC domain > > whenever possible. > > I admit yet to look fully at the series. But I must ask, why are you deferring > to load balance and not looking at wake up path? LB should be for corrections. > When wake up path is doing wrong decision all the time, LB (which is super slow > to react) is too late to start grouping tasks? What am I missing? There used to be wakeup steering, but I'm not sure that still exists in this version (still need to read beyond the first few patches). It isn't hard to add. But I think Tim and Chen have mostly been looking at 'enterprise' workloads. > In my head Core Scheduling is already doing what we want. We just need to > extend it to be a bit more relaxed (best effort rather than completely strict > for security reasons today). This will be a lot more flexible and will allow > tasks to be co-located from the get-go. And it will defer the responsibility of > tagging to userspace. If they do better or worse, it's on them :) It seems you > already hit a corner case where the grouping was a bad idea and doing some > magic with thread numbers to alleviate it. No, Core scheduling does completely the wrong thing. Core scheduling is set up to do co-scheduling, because that's what was required for that whole speculation trainwreck. And that is very much not what you want or need here. You simply want a preference to co-locate things that use the same data. Which really is a completely different thing. > FWIW I have come across cases on mobile world were co-locating on a cluster or > a 'big' core with big L2 cache can benefit a small group of tasks. So the > concept is generally beneficial as cache hierarchies are not symmetrical in > more systems now. Even on symmetrical systems, there can be cases made where > two small data dependent task can benefit from packing on a single CPU. Sure, we all know this. pipe-bench is a prime example, it flies if you co-locate them on the same CPU. It tanks if you pull them apart (except SMT siblings, those are mostly good too). > I know this changes the direction being made here; but I strongly believe the > right way is to extend wake up path rather than lump it solely in LB (IIUC). You're really going to need both, and LB really is the more complicated part. On a busy/loaded system, LB will completely wreck things for you if it doesn't play ball.