From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wm1-f51.google.com (mail-wm1-f51.google.com [209.85.128.51]) (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 5B7C1B652 for ; Fri, 20 Feb 2026 03:29:45 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.128.51 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1771558186; cv=none; b=F+JYrOAc6ab/3kQ0vOu0fNAkpZ9gUy7j30AVWrpw8hnSaKMSi1Z/gybktHAn8oYpU+QiSm7EFe2LoLOkLp+/YVyaLiH3r42d2l70jdD8/v1ISfUhckdVy3CKeCfPds3hGRI9HK/RWwa0Sf0u9MzCiKQvY8o93YhaO5zT2nkFgr0= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1771558186; c=relaxed/simple; bh=Odt872SMrsP9wMFtlbIUfRtR/oE7wCJBl+ZiJ96d0h0=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=tAeOaTL9jY1n//6CXwL0Knmk7MZXOgsCh9CqwHCRL+LG4zhT7j4rcmWETY37a/5FByp49SPlMBxBuUkO2t7rm1d7ONaDueWAR7qh0Hv2nDcfG6OD7+nh8ePequDdjTiIom0Bl6ii/A0IU1LrrtXZttSOYBMoq4EObZb/PnhTyR8= 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=HF2w/SO5; arc=none smtp.client-ip=209.85.128.51 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="HF2w/SO5" Received: by mail-wm1-f51.google.com with SMTP id 5b1f17b1804b1-4806ce0f97bso12603665e9.0 for ; Thu, 19 Feb 2026 19:29:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=layalina-io.20230601.gappssmtp.com; s=20230601; t=1771558183; x=1772162983; 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=6rmJ1qvabXaBkJDtlV54ZJkTh52yqo8rG2xQDuMOMCg=; b=HF2w/SO5Ta+Ep6nJ0V3NA0+CRzHhYH+RmNBvnA5Dkab8E4rS0VlhWFs2wQ/CQcN1j9 +k9yX/0NV3qcbsGpcxi/ZqU7rUIOiFXHRKqVBS8Ajmj/kfjzbVnY8mKU+F3uw7yCe1es cLkk0jHFs/sW18fSoeB7I6fzbcqvQk/x8ODv8fyROL3CPk72O+nW13suBFKeBfaNplUw 40XbbXNGc2QgLkwt5EaUZFYHy/RH4+tGfzZkyOipMCPGaqzS4BcCfr+1W+DN3TAWWH1+ TI7bhwcOlj3t9kzeXbyhKb/XzHZBBNeKyYsB0LLM1UDGIHS45JUj3F1+JCzJ5n8jUI+b dZzQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1771558183; x=1772162983; 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=6rmJ1qvabXaBkJDtlV54ZJkTh52yqo8rG2xQDuMOMCg=; b=fzfgMTVzFs2W7btywQq/VTRWFLHRzsxTDyDgxWX6CkQQjDAUABxU9N1vbGq7ZFn+Wp LHAo/PiMdwfIPHjAXHoUZJpICbJ8pUPJY2cqmfGTQMjVdiC+YoRJ/wo6Xi5pCcsweA2l vpRwEXPlPhPxqnEdzKOf7NXYV1+Cw1umi6UKv59W+pTBnwn2kCevV0gMOC4E1rvVVJAI jo54qSMZuVxileZ3gJQrtJmWG13gJDZO8e405QbAYHLihcTTp6vKNMxx6BXdwg2aoiSi hcK9TXber1T5s10pJod2jIXz0APxcNgQSMgTDQygTpudd/w+bXUJQfpIoqgsKn0bnLK3 xVJw== X-Forwarded-Encrypted: i=1; AJvYcCWnyZ1aJVGPlauhsUiRonq0b1iMpenqegPKpYptodnx2kS0iVVby7myiO/hTMcVv5RGpODtGAU6CsLNucw=@vger.kernel.org X-Gm-Message-State: AOJu0YwpA2EGgG/JtZbt2SVmolS6Arl0XLkf1huH8ZzbyPRtiZ38wSWg 1nLtg2UIMYHFkE05OkUDN5hybyFfMOcingiC8+8+9HiQsz85HzMj0GToms2u1hUuBDY= X-Gm-Gg: AZuq6aI3b7jgVgyCuHfd2qSvIRRuRJPG6cNt9Ta8FVTF/UwHRgmsFpcPnNCJuI7tGwy UaTZ9pTTZQfz6FXQjD+QMKk/9QX4iLAnVRPxQ95sX9KRNoa4pCL2uKII9QKQKTaTbxLfYxETr7e sq5CAM6BeLiP24/04g81AVwAyug9Qz1q7KsaQnI79Qu3GWW7fBtJXdyj9VcTGhyjpC6wGQAh9Ba tain2uB3RwBStSeyruu3JnveTEQXpbM/FsuEOMxQf0sxpJP2u+pRWoOI+hM/mkd9zVz3C00ZhOR q0X1bLVJT6HxxNBmxZ5trlz+/3fkeCzGObdQd8d6ue3dkg/MOmwLuJlFIXyiJVQbtCuosk32zaw XAXR6T8rOG9R7BnWlpvzt4xYQhBKz14mQBlF00Yb9lCV0lt2cELYcf4ziIvSU598X8Wgq/R/uAP JZKerXCUVXAhVA9bIUOgnpN6QvNSicFgdhSHov59sJ4IPtGiMIH8RSXU8dEtFtq3y8Eapm X-Received: by 2002:a05:600c:450c:b0:471:700:f281 with SMTP id 5b1f17b1804b1-48398ae4a01mr135233395e9.25.1771558183382; Thu, 19 Feb 2026 19:29:43 -0800 (PST) Received: from airbuntu (host86-169-41-76.range86-169.btcentralplus.com. [86.169.41.76]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-483a31d82a8sm38561735e9.15.2026.02.19.19.29.42 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 19 Feb 2026 19:29:42 -0800 (PST) Date: Fri, 20 Feb 2026 03:29:41 +0000 From: Qais Yousef To: Tim Chen Cc: "Chen, Yu C" , 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 , 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: <20260220032941.cw7zdlcy7n6fxmsj@airbuntu> References: <20260219140828.a7pyzupun7lsdw34@airbuntu> <20260219144108.GI1282955@noisy.programming.kicks-ass.net> <66a23acb-973e-4987-a006-18c50e18d3aa@intel.com> <4514b6aef56d0ae144ebd56df9211c6599744633.camel@linux.intel.com> 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: <4514b6aef56d0ae144ebd56df9211c6599744633.camel@linux.intel.com> On 02/19/26 10:11, Tim Chen wrote: > On Thu, 2026-02-19 at 23:07 +0800, Chen, Yu C wrote: > > Hi Peter, Qais, > > > > On 2/19/2026 10:41 PM, Peter Zijlstra wrote: > > > On Thu, Feb 19, 2026 at 02:08:28PM +0000, Qais Yousef wrote: > > > > On 02/10/26 14:18, Tim Chen wrote: > > > > [ ... ] > > > > > > > > > > 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. > > > > > > > Please let me explain a little more about why we did this in the > > load balance path. Yes, the original version implemented cache-aware > > scheduling only in the wakeup path. According to our testing, this appeared > > to cause some task bouncing issues across LLCs. This was due to conflicts > > with the legacy load balancer, which tries to spread tasks to different > > LLCs. > > So as Peter said, the load balancer should be taken care of anyway. Later, > > we kept only the cache aware logic in the load balancer, and the test > > results > > became much more stable, so we kept it as is. The wakeup path more or less > > aggregates the wakees(threads within the same process) within the LLC in > > the > > wakeup fast path, so we have not changed it for now. > > > > Let me copy the changelog from the previous patch version: > > > > " > > In previous versions, aggregation of tasks were done in the > > wake up path, without making load balancing paths aware of > > LLC (Last-Level-Cache) preference. This led to the following > > problems: > > > > 1) Aggregation of tasks during wake up led to load imbalance > > between LLCs > > 2) Load balancing tried to even out the load between LLCs > > 3) Wake up tasks aggregation happened at a faster rate and > > load balancing moved tasks in opposite directions, leading > > to continuous and excessive task migrations and regressions > > in benchmarks like schbench. > > > > In this version, load balancing is made cache-aware. The main > > idea of cache-aware load balancing consists of two parts: > > > > 1) Identify tasks that prefer to run on their hottest LLC and > > move them there. > > 2) Prevent generic load balancing from moving a task out of > > its hottest LLC. > > " > > > > Another reason why we moved away from doing things in the wake up > path is load imbalance consideration. Wake up path does not have > the most up to date load information in the LLC sched domains as > in the load balance path. So you may actually have everyone rushed What's the reason wake up doesn't have the latest info? Is this a limitation of these large systems where stats updates are too expensive to do? Is it not fixable at all? > into each's favorite LLC and causes LLC overload. And load balance > will have to undo this. This led to frequent task migrations that > hurts performance. > > It is better to consider LLC preference in the load balance path > so we can aggregate tasks while still keeping load imbalance under > control. > > Tim