From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wr1-f53.google.com (mail-wr1-f53.google.com [209.85.221.53]) (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 13AB0271A7C for ; Thu, 19 Feb 2026 14:08:31 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.221.53 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1771510114; cv=none; b=B5tB6I46KIT6p09s7+FI5KrmSMhO9GlQFdWnmT5/m8x5oo+mlkR6QSM5ZSJCnrgNfk8rpYTRmY3P1uBmcQbCLFKDPvBBmdqANMTm33UsYke3OgbsP9ECcOu0jZKejn5rX2yaGELlCrEQIPINJDolArgSWZMnamaqhAlSf1io9Rs= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1771510114; c=relaxed/simple; bh=fdwCAfVKLiM1thTM/xcOKJHBzM79spUQgMu7rS7EhQw=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=PA3gGBFMv4MrjpSY8sY+gePWufN4BS58Qr9LW/W/XJDWXvlFMlkTlK35lNSI4fYrBNlJdOQyfYV7eJhXJMpGeEQcB8zbxkOWVn5pVdUmK+iArw4ghB5/8/P8XC5mXxOJ993isBcQ0I8XLkG1C9mXF8Utye2U0kOWgT8pFLnNh9M= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=layalina.io; spf=pass smtp.mailfrom=layalina.io; dkim=pass (2048-bit key) header.d=layalina-io.20230601.gappssmtp.com header.i=@layalina-io.20230601.gappssmtp.com header.b=lvVcl53X; arc=none smtp.client-ip=209.85.221.53 Authentication-Results: smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=layalina.io Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=layalina.io Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=layalina-io.20230601.gappssmtp.com header.i=@layalina-io.20230601.gappssmtp.com header.b="lvVcl53X" Received: by mail-wr1-f53.google.com with SMTP id ffacd0b85a97d-4376de3f128so670319f8f.0 for ; Thu, 19 Feb 2026 06:08:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=layalina-io.20230601.gappssmtp.com; s=20230601; t=1771510110; x=1772114910; darn=vger.kernel.org; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=u4Sv/MqDtXuQbsmKGuMalOOFqxFyktmmpa9JpT3vXGQ=; b=lvVcl53XLWhi3gcW0PbJ5GinBy8KoyUkIoLaEHAV/dwF7UP8RII5JYyf/HYbGQukQS SAuLvWF3H/o3Bk3XHAATWRAsgt5b0QsjhcND3falxaqZrbxukxMPWmPSHzndtpSBxEoO 5THyIZB1A9fGUk3Vi93PjLl4tEm7s9oOYY7WPGHtnJziIFQHtj8VYu+MQgdMvD1thsAV mvA5CRUEqhKqRDEPfeLFn8ZCb4a6uLQsZ8497vSLRNMSApOu4GPfC62GJ5A1p0THQpAO UAAE91hZ4HP0wN6AUzZm6RNLOhDQhCkJKehmgNnsUCzCJEJhs4JhfdYav1YItrRQKChD g8CA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1771510110; x=1772114910; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-gg:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=u4Sv/MqDtXuQbsmKGuMalOOFqxFyktmmpa9JpT3vXGQ=; b=w4g408d03yVwy01Qg7opUcs6jqC9+TjfISueyLzdt2QwU3Tayyn3waDjPWp3cFVzOm xGxk0IbN86WkIXgTyRXz7JYDNpYD9fTehxX1CeXnYZnh7eQ3oHGYXwnblnBiYJUy4PfR KO7Lk19GI7lAbfJU5A0pIeAst01luyAutnGktARmBATAfGIqwJV7+dSkUbVOBrIelgHq Ekicrn79qtJ/0jbMqsXygSygOQVCXOncGa1+wDSr2ORZ0fYGX7rKnY4d0HeVHkaPDYOe XOKudz9v3QMZQh6UzAdGnwAMSAY39eWZIJ6KfFhBJGAvt2PpXtw7/2XU2Z3BzeMqlp/a Kujw== X-Forwarded-Encrypted: i=1; AJvYcCXOphjyIsv62YcIGqvWUTQHS4Tsydm9FF1G8r5qIjxuk+uPZnUdyyEOi15/+MbJlZMpK0jmkL/2bpQHWhg=@vger.kernel.org X-Gm-Message-State: AOJu0YyApGewtyachIQdFQPkKkNMzHUg+BYg7kzJB6NoyOjxMx5+6DhK VIz9MuSDky5hlLZYQdJAlhuiF2trlmXz9vdw09wRvCpvSPpJ7c4ZK1SE4NfitmGyB5E= X-Gm-Gg: AZuq6aJKu4foEi8Szgz5fpgL5VodGDInrEArf8wReDSf4hQnJZRUvbCuoFBiIKuOq6y lt6Ym9STwxg7JmwInpV05nzGQuz7FeHTkyyL2IKC2yYTJmZtMONs5RsxdlgBA8kLREA+b8PDbzO 6GCtwm4Uaq86oKFDmtXXFPBI2mU75SZLJzt9Li2JYAQ8kr24VZ9oKukWytvrCq3T1/i7J9wdxaj JYZ0AhA2YAs8fA83hZ9Lm1QrXcSRSg2GwCL+dcIqDNZHGmbLVgvvXimOgcJSbazqkJ4yTKcLHjC 95q0ZoQva7A7OmfhSlHVrRmCvYwdfLNhAH8Y6p2h5BVS3M1naaQZ5t704tp8haIulch5tUXd/pQ q+W6755eBLPI/ebojni6O/2CS4bE9vaiI69lApu8jAW8hoYsy4Gl0O+g3tZYUGeAMwfq5/0Y2nR Bxr/uUpmNxxmSHES2uQLgJkuz7NSQkIdG4Lss/dlTgGOL50gWjVYyCFCbGrnnXhxPXZb7g X-Received: by 2002:a05:6000:1ac6:b0:437:678a:5924 with SMTP id ffacd0b85a97d-4379db98627mr36368241f8f.32.1771510109952; Thu, 19 Feb 2026 06:08:29 -0800 (PST) Received: from airbuntu (host86-169-41-76.range86-169.btcentralplus.com. [86.169.41.76]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-43796a5b4cdsm52847677f8f.8.2026.02.19.06.08.28 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 19 Feb 2026 06:08:29 -0800 (PST) Date: Thu, 19 Feb 2026 14:08:28 +0000 From: Qais Yousef To: Tim Chen Cc: Peter Zijlstra , 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: <20260219140828.a7pyzupun7lsdw34@airbuntu> References: 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=utf-8 Content-Disposition: inline In-Reply-To: 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. > 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? 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. 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. 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). Note I am looking at NETLINK to enable our proposed Sched QoS library to listen to critical events like a process being created and tasks being forked to auto tag them. Userspace would be easily able to tag individual tasks as co-dependent or ask for a whole process to be tagged as such (assign the same cookie to all forked tasks for that process). We should not need to do any magic in the kernel then other than provide the mechanisms to shoot themselves in the foot (or do better ;-))