From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wm1-f45.google.com (mail-wm1-f45.google.com [209.85.128.45]) (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 BA31F749C for ; Tue, 24 Feb 2026 03:02:33 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.128.45 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1771902155; cv=none; b=ThI6lsGxLWTPea/JXGDNKkysfOjlC1ZcXIySTG5aq/eiVVLJhA1/aiooa1vhR/5fL8v/P4zM9yRcjsMJTpv1yLQ+8e9woF11QPjBpcPCsTJSGre3+5oWiTv9ZqUY9s8RqJMXhMGUzSYBLhw4nhi2yfnfHogYDyXeBBVfZerRQR0= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1771902155; c=relaxed/simple; bh=Ngvidh9uYa4+9CSyukl0WRW5u+BVxgsP7mmYiRd+zYE=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=r71w3zEenGy/FKTslUKm6Y+Gv4mWXfWbOLeB1ow1PGK8JQhqqcfnTHgSQl6i68QJFiyhzZvarDdWst1x7VPs3THAb79gYINIW1XTWc1Dlbzpb25kqtlKnhEIfc26DKBaqzW9UOuzh9a5PcHZpIWq9+iG9E0pJLEGxsqq7gSD3xs= 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=0p1RpHYw; arc=none smtp.client-ip=209.85.128.45 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="0p1RpHYw" Received: by mail-wm1-f45.google.com with SMTP id 5b1f17b1804b1-48329eb96a7so28977105e9.3 for ; Mon, 23 Feb 2026 19:02:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=layalina-io.20230601.gappssmtp.com; s=20230601; t=1771902152; x=1772506952; 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=8wxDTtkhDkVRZ18kUGany3wFaokdSXZ6+1er1o2AMxY=; b=0p1RpHYwOopFPv7BfiyTkBRJNdcooJIBGwwqlibi3PWzNsKGhAP+3VQgny1QyaSJ6m r0wzWb8R/q6fUGSt1Cd8nuok0YmXl0k1yKnub+RwBQHAy0QTL61LZcdwlzo+Ant9sFSY CYsMvdzv5XLCDz+7zsH5ze41TbeMslaErFD9UZJGku9jjHZY9vCrOVGsX/JFNL09C+X8 ck6cFXQ+hTS1OS6G4F34dGjQbLeePgkuWkXNQya83VtPdPdKe8lii6ULo5wsbaw6nLqW /4nGBlKx79SPcW2q3PBojf/I+XH5te01UggwQuXiROIRx/4qrNb6W8drM864GF+XPoUX W9bQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1771902152; x=1772506952; 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=8wxDTtkhDkVRZ18kUGany3wFaokdSXZ6+1er1o2AMxY=; b=DyLD9OxBg06I5Wc0AnbDQg6vIjrMDDkGTwuam6G7eYiFMgTZpjy11xKRCwgguHR6XR GK+9p64hzDYQz5y1MntdqpNx28SH+JH/rmuaJ5cWUFkfBDjPeOAryaGsOzhgTfLuUdoy F7O2NIGnN8Gg4Z5/SVQkO6A/aDmz0sRB360Z1YFSQhz59bVv+ce/wyK00II5NzjaHF73 xhDaXCtos9j9KJsa3GYBbk5vmbqUMXrfOu6LxEwv9mkef6Zt+S3tOfqY9zznacNcYl2k OFLqLnVOYVyW+/k97GB0qHvCyC62ZBKdeBcC5m9QtDVOsMD3xz+tUOzG6+pKWn1oW4ml fXrQ== X-Forwarded-Encrypted: i=1; AJvYcCWxevoAFfvS4esLgpi2L2QP3hAAa3FV7y7A4srdVA245r6ULx5oSdPpKQ38T/Jz7zmiKYu0RYyrCH+KJYY=@vger.kernel.org X-Gm-Message-State: AOJu0YwTv8t85fE4FQcU5VAYNFazWHsl+PSojDCp/JnMeUZ8XGlPaI/4 pL2dLmBNlAG8winwQNkUk1lcFXb1fQrtA/RYjZYCZxY5EJfeCQ5IHwii1JQc5r6XZos= X-Gm-Gg: AZuq6aLhcdS2LJMDSudqnFJrYfxzOT+7A482x79NMekPuOi0Gkf2eKsAVYIaBHvULUv qxxDD9DaRYcPwlHhZGFwiaMNyYQP1q3Sz9R52arKC3QXDgVZZ5uZIvMGet/aBFlVJvm8Pe7PmFi YjorjEzi5pnFkmPrYRZRoBfmlu00dpqOG+qTCNHfmGdP8s54R/Q/7raGVSFtdYHugMoZXT0aM5a cPbTasbQ9RJK1Jjr3XmX4Oi5wbg9L4VMVHxZqsvwK2V5xWLecOZ9sVtk6ZezOG8O0GIPYIV25nP gPGyIL4Bh+VYTzuBlUtT4TEAibcnWEpzSq8pYCq7v5YIhXd/H6kCsvgvVlJvdcfr1S/0M/rlgqm FpcSv+zc5xnPEYjXaK3clt5iDp94//GqSNId4vygN2aIyrhqKUrYfvTcI/7hX3twQGuhURUHzPR WaR06APIzrEVr0DP/H1BM2H4PDBFeyleo6rRqYXF1x9MIYawlGVosWkTLOlD5nbz2oamYi X-Received: by 2002:a05:600c:450c:b0:483:75f1:54f with SMTP id 5b1f17b1804b1-483b80c9ea4mr28130985e9.31.1771902151714; Mon, 23 Feb 2026 19:02:31 -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-483a31f9af5sm285467605e9.12.2026.02.23.19.02.30 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 23 Feb 2026 19:02:31 -0800 (PST) Date: Tue, 24 Feb 2026 03:02:29 +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: <20260224030229.wlaqyf5byi3d3mtk@airbuntu> References: <20260219140828.a7pyzupun7lsdw34@airbuntu> <20260219144108.GI1282955@noisy.programming.kicks-ass.net> <66a23acb-973e-4987-a006-18c50e18d3aa@intel.com> <4514b6aef56d0ae144ebd56df9211c6599744633.camel@linux.intel.com> <20260220032941.cw7zdlcy7n6fxmsj@airbuntu> <43645f25299018e91fcf7464b8f389787c0e9419.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: <43645f25299018e91fcf7464b8f389787c0e9419.camel@linux.intel.com> On 02/20/26 10:14, Tim Chen wrote: > > > 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? > > You will need to sum the load for each run queue for each LLC to get > an accurate picture. That will be too expensive on the wake up path. I am probably missing something obvious. But it seems enqueue/dequeue + TICK are not keeping stats enough up-to-date for wakeup path to rely on. I need to read this code more. I could be wrong, but as I was trying to highlight in other places, I think the fact we tag all tasks belonging to a process as needing to stay together is exaggerating this problem. First every process is assumed to need to stay within the same LLC, and every task within the process. The wake up path by design now has a more difficult job and needs to look harder compared to if the tagging was more conservative. And I can appreciate defining and teaching regular LB that some imbalances are okay under these situations is hard. It is sort of overcommit situation by design. Anyway. As I was trying to tell Peter, I am trying to think how we can tie all these similar stories together. I hope once we can provide sensible way to tag tasks we can get wake up path + push lb to work easily as then we should have a handful of tasks asking to co-locate which is much easier to manage.