From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-pf1-f195.google.com (mail-pf1-f195.google.com [209.85.210.195]) (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 44A15258ECB for ; Fri, 19 Dec 2025 04:01:54 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.210.195 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1766116915; cv=none; b=QO7xUBWXSxBHAjJ/Mnmpdl1/A7nwa3viPgDSmNIoxCpB++neRzRymKC2TEFZfozJ+O9qOm2JSUyi5R6vVxMngF/VvU59F/L3X8YLik2KXqFbqGJWD+F/Pg80w6w29bcERZNlb7XUBqeS5dteFUB+bOVNvkznxzn84V5XkCWIpJQ= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1766116915; c=relaxed/simple; bh=AdIrA7T71GxApbevD5svbhLXFA3EywECebjD/tr2kL4=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=Vb8u+H5gwduoS7gEmj/sGqGsmT9S1kkK9yafpLKxq7GLNTsJ5gAEg1YeJJZQujlYk6rCXqq0hYQgR4RrIrkmCQpw+Hc+QSWzqrwLXxjeaLInnS0EGDzoG+jtEM4pxa9idHC0GyGpK0X+tDJkjkJFZFr5rOl76EW/0FHbxFGUHRw= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=hoD+XrsU; arc=none smtp.client-ip=209.85.210.195 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="hoD+XrsU" Received: by mail-pf1-f195.google.com with SMTP id d2e1a72fcca58-7a9c64dfa8aso1096651b3a.3 for ; Thu, 18 Dec 2025 20:01:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1766116913; x=1766721713; darn=vger.kernel.org; h=content-transfer-encoding:in-reply-to:from:references:cc:to:subject :user-agent:mime-version:date:message-id:from:to:cc:subject:date :message-id:reply-to; bh=t/eN8F1lomOjJP3ohwkU0/GhIFlnaCqwg77C0QbjcYs=; b=hoD+XrsU4fdRS2v+RY4lUfDZKRZ1bQDv1gY31UHkvxFg5sDW5JGCh35VQT6IQSvHCk MkEZvF6ti/P0spFZQ7PC+E1iiWhBiEHAXvgqB7ELES/oa0mdQXGRtsrVtI9Z0Fnjo2vx 7kbqboCaqF8WR8sWw2NM5BzjDr13tgYg20BgpwokRCyQPjaPN8mxNrZm3fivrN4/aOR1 lKR/dhf0gwWKlhz+jdHzG+4inE6EalHMBuQWpmsN0+JmbSpLa4KZNhrHSthCEgBDzt+a OumGpjGQv/mCWYISiOGA3ef5gmemO7+er3BfFge4RN+1fYo4miOOZiUgLozJrYoiqv60 MQKg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1766116913; x=1766721713; h=content-transfer-encoding:in-reply-to:from:references:cc:to:subject :user-agent:mime-version:date:message-id:x-gm-gg:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=t/eN8F1lomOjJP3ohwkU0/GhIFlnaCqwg77C0QbjcYs=; b=sYaY9OCbmxL/xfcV3i+/md1KbDbQ7EBW59yRsuIINKs3L25aX1Wm8kDysqNDon73Yt OzcJsdXjAtcrlTqu9onsYeJGrvDMWwJFITKIZ/fCw0mhN5sI6hyPoWxVQf4wqng2aCo5 ofRRn+Veb3IZ9S8OVaoZ2E/TVpUFlhD8FNOLeiviuWmbhKGk/I17M1hTy/SA6Eh6u2vH StGtybafFeuQkP3TGv01ZL0AHYJeBW+ZgQCDQcqaX8NleBxw9rVnyIGMSvZaZ81aI3da tX7BglV2f/wLIP7Pld5+BwAMNtckQlYDUJEul31xZV8nn3iwiRFo8t8qtGwPzObSkjKq cD0Q== X-Forwarded-Encrypted: i=1; AJvYcCWtfxo5cHnyyXFASeav+C9tzz1lJge1ssG6RNVacPNVkLbHgIA/iDDxwJpeShMQAzrHjSheyybZhpvjxpU=@vger.kernel.org X-Gm-Message-State: AOJu0Ywe8i85V4frUaJtsQqJpK5Np+KjaOGJmB3MehKCLVRR16W0LsgV SDnsW7PlpNBE+GvhuEcFGSkfGglWG4JIw9Kaazlmn/UxjZ7YPTEs830V X-Gm-Gg: AY/fxX6NNM1vumiylx1j7zu4daeE+eK63Eml7/4iPnmwKPKXtLU+8wUvIkqbLswzK8H T3/pM2CyqOJS7Xdn1Y0YyzoTM4sle5eZUXkkRU2buaKyHYRfBcQDQffE5bo7VqXtIUojzTbMKEe FhTtktq5wFodZ9BPh8eHogxSmxD7LoLUElhKqE3CJHnS02hqvOpN+dUkkOAJL9JKPFgx3SOlwON CGJYzQ/A5ASY7Wr304pjDMaFdFQOMfUpFUr+CZa4FteYkbJ04VVzk+OqVcw1/wC0+HGdyET1/L6 1m0HAUO0l2JRtDkmYwYUVF3Ican93M6MVNZZFNmjISXY98e68+P8EcZIyq/3HclkQI/K6Y8tX9J CTDIVdsiEzMX6vziAV7SxfbeBudqOwaZaTxBsl3GbmFYsB58hmhxp6d1O6bA/SF9/BA3Rx1xdOO nCaQ9p9TwDMtevwl3zR8MNwtGm7nkyZMPybKG2zQ== X-Google-Smtp-Source: AGHT+IE5qouzEazdPn6+rm97PPRtxv7bnIcE/Yr4OEdun9q/lqGSVUGewshJcTcbKBw277IOF2A91Q== X-Received: by 2002:a05:6a00:800d:b0:7e8:43f5:bd4a with SMTP id d2e1a72fcca58-7ff67258d0bmr1316337b3a.54.1766116913479; Thu, 18 Dec 2025 20:01:53 -0800 (PST) Received: from [192.168.255.10] ([43.132.141.25]) by smtp.gmail.com with ESMTPSA id d2e1a72fcca58-7ff7eb87bfcsm793715b3a.69.2025.12.18.20.01.47 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 18 Dec 2025 20:01:52 -0800 (PST) Message-ID: <15faefaa-7460-41dc-a44c-989d51d83451@gmail.com> Date: Fri, 19 Dec 2025 12:01:45 +0800 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 v2 05/23] sched/cache: Assign preferred LLC ID to processes To: Tim Chen , Peter Zijlstra , Ingo Molnar , K Prateek Nayak , "Gautham R . Shenoy" , Vincent Guittot Cc: 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 , Len Brown , Aubrey Li , Zhao Liu , Chen Yu , Chen Yu , Adam Li , Aaron Lu , Tim Chen , linux-kernel@vger.kernel.org, Vern Hao References: From: Vern Hao In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit On 2025/12/16 03:32, Tim Chen wrote: > On Fri, 2025-12-12 at 11:34 +0800, Vern Hao wrote: >> On 2025/12/4 07:07, Tim Chen wrote: >>> With cache-aware scheduling enabled, each task is assigned a >>> preferred LLC ID. This allows quick identification of the LLC domain >>> where the task prefers to run, similar to numa_preferred_nid in >>> NUMA balancing. >>> >>> Signed-off-by: Tim Chen >>> --- >>> >>> Notes: >>> v1->v2: Align preferred LLC with NUMA balancing's preferred node. >>> >>> include/linux/sched.h | 1 + >>> init/init_task.c | 3 +++ >>> kernel/sched/fair.c | 18 ++++++++++++++++++ >>> 3 files changed, 22 insertions(+) >>> >>> diff --git a/include/linux/sched.h b/include/linux/sched.h >>> index 278b529c91df..1ad46220cd04 100644 >>> --- a/include/linux/sched.h >>> +++ b/include/linux/sched.h >>> @@ -1408,6 +1408,7 @@ struct task_struct { >>> >>> #ifdef CONFIG_SCHED_CACHE >>> struct callback_head cache_work; >>> + int preferred_llc; >>> #endif >>> >>> #ifdef CONFIG_RSEQ >>> diff --git a/init/init_task.c b/init/init_task.c >>> index a55e2189206f..44bae72b5b7d 100644 >>> --- a/init/init_task.c >>> +++ b/init/init_task.c >>> @@ -191,6 +191,9 @@ struct task_struct init_task __aligned(L1_CACHE_BYTES) = { >>> .numa_group = NULL, >>> .numa_faults = NULL, >>> #endif >>> +#ifdef CONFIG_SCHED_CACHE >>> + .preferred_llc = -1, >>> +#endif >>> #if defined(CONFIG_KASAN_GENERIC) || defined(CONFIG_KASAN_SW_TAGS) >>> .kasan_depth = 1, >>> #endif >>> diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c >>> index 0a3918269906..10cec83f65d5 100644 >>> --- a/kernel/sched/fair.c >>> +++ b/kernel/sched/fair.c >>> @@ -1300,6 +1300,7 @@ void account_mm_sched(struct rq *rq, struct task_struct *p, s64 delta_exec) >>> struct mm_struct *mm = p->mm; >>> struct mm_sched *pcpu_sched; >>> unsigned long epoch; >>> + int mm_sched_llc = -1; >>> >>> if (!sched_cache_enabled()) >>> return; >>> @@ -1330,6 +1331,23 @@ void account_mm_sched(struct rq *rq, struct task_struct *p, s64 delta_exec) >>> if (mm->mm_sched_cpu != -1) >>> mm->mm_sched_cpu = -1; >>> } >>> + >>> + if (mm->mm_sched_cpu != -1) { >>> + mm_sched_llc = llc_id(mm->mm_sched_cpu); >>> + >>> +#ifdef CONFIG_NUMA_BALANCING >>> + /* >>> + * Don't assign preferred LLC if it >>> + * conflicts with NUMA balancing. >>> + */ >>> + if (p->numa_preferred_nid >= 0 && >> I wonder if the restriction here shouldn't be so strict. In Mel Gorman's >> patch (e496132ebedd sched/fair: Adjust the allowed NUMA imbalance when >> SD_NUMA spans multiple LLCs), the value of the 'imb_numa_nr' is checked >> to determine if |SD_NUMA| imbalance is allowed. Could we use this same >> check to decide whether or not to perform a cross-numa migration? > If we set the preferred LLC that's in a different node other than the preferred > node, the preferred LLC is going to fight with NUMA balancing and bounce > tasks back and forth between nodes. NUMA locality is going to affect performance > more so we'll let NUMA preference take precedence. I might not have explained myself clearly. I’m questioning whether we need to integrate an imbalance check into the 'sgs->group_type|' is ’group_has_spare|' scenario,  like Mel’s patch, to refine our llc migration decisions. just like this:  8 cpus in one LLC, LLC-A has 6 tasks,  LLC-B has 2 tasks, if LLC-A has task_a need to migrate to LLC_B, how to deal it ? > Tim > >>> + cpu_to_node(mm->mm_sched_cpu) != p->numa_preferred_nid) >>> + mm_sched_llc = -1; >>> +#endif >>> + } >>> + >>> + if (p->preferred_llc != mm_sched_llc) >>> + p->preferred_llc = mm_sched_llc; >>> } >>> >>> static void task_tick_cache(struct rq *rq, struct task_struct *p)