From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-pf1-f178.google.com (mail-pf1-f178.google.com [209.85.210.178]) (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 4D4BD308F11 for ; Fri, 12 Dec 2025 03:34:59 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.210.178 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1765510503; cv=none; b=kpQdOwM08m/j7Ca4pv+taVtFtgyCr74xUIc9Hzf7U7GEgYXuiKhQRSBqwlY90JceHs5YizjrSdn1MAldPSc3EYMLlYS85Hbaw7HXL1SeHpCuUFsyiGSJhSTE7vqIu3xs5LdZWBKiNYSL0EOd/ETgbpHAO2hP0tMquU8VoQvVW9g= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1765510503; c=relaxed/simple; bh=NccfJ2O+lejfta6sTESvSizJ5gqD6eIH3eaubqq94EI=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=AJH6FPt8gZPFCjGkGwx4F+1QgD3N5Pa5CORCQeSwCMEvHRvz+3Ea/sEoKXRPDURBgr17Wvi69FcD5RdkpTw+epAWIVzy+2BBHhbKJk2YXKLfwIgXxI7lj+OcROwRmL6Ixir/r4+QdakqSOhOiyUB8Rmtd0Yaj16iKXKieHYGGaQ= 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=bRHQaxJ4; arc=none smtp.client-ip=209.85.210.178 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="bRHQaxJ4" Received: by mail-pf1-f178.google.com with SMTP id d2e1a72fcca58-7b75e366866so353809b3a.2 for ; Thu, 11 Dec 2025 19:34:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1765510498; x=1766115298; 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=yf5+xRWv/vZozyPZ4Y2hizpuJidH/2QWNdESSAwoYD0=; b=bRHQaxJ4EfC+spaQRPsFSSNxDVss3VYo/GXIHjF0sSK+nIt52c3A3mwub8SLGNnR0f gIN3zF7s5xumG9R3DsAH16kZFdFMdgVLZovx7Z3lZHMGZJQddj72vIdySCjxe5rmiaWY 5kH59eRA31dsGWIXpetmoenL3pmUdhCAqhd1idkPvGppgeqGVw8o/cuPgfLQZbXqBiI7 ecZIBQclZhlyvGMq81ot1PzrPrhN1PsgPr0XxB0WZFl2yDKuHq9HKzYeLXKquY7jvWnx pgY2rLtIDsDrC9mnljzTdd5GM96zcnW0wRnsQPl+bUpJZqUKtzd45zUlEvM3z0/TeDEu 3uLA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1765510498; x=1766115298; 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=yf5+xRWv/vZozyPZ4Y2hizpuJidH/2QWNdESSAwoYD0=; b=wy0wEd6Ghi2wMOm8X23QnoouL3BhHPgyZ8IwPSi+3VsNkxp+4ip3XIcZwL1oN/iJyV 4mZaF/BWYX8wZeg3qL0bRHTia88bH5pgAlC4+pBFM9MERsNNv+C9wP6aDh90GtgaXxjm U9G955bl6xytAiAHctHVRWYDBA1Mjj8fGu/o+kumLDORgoA9ICGR3/CSjT2sfCDGi9v/ xEfIFXFwOjOZqzW+W+Ov/LNHGBBlltRSSJkX4P5lEYC4UB1hejwulBF0J+/oSWMH6IOc DVzpTfRZDP/wRDRFxJAWxsdjrcV4bkTn8GkMr0jnF2xYRYiKYWmfbB0RJmGMFQeMVJVH xWKA== X-Forwarded-Encrypted: i=1; AJvYcCXpnq7jvgNfZDEc7VYjzOybbgKIYd+GkdqGu4dhti2egTYvG5VSQ7ESVA3wkpPNU/ssUMLPsuCKCOKkNRo=@vger.kernel.org X-Gm-Message-State: AOJu0YxBo1JNEizZl4eOXnC7NmspeG+Ge7GEbZsvKCZfAu3y40HNRcpr m5aFHWGcQP9TIAnM7sv4HB1nEGe5OeAkyJ3fcfZXQ6vMa4oN65E3XY3Q X-Gm-Gg: AY/fxX5R+3OrUo/VB8YYPmpAF9oha8tcA9+QLhY5esJrxcUyG91bfqkyf/4U9mVT/9e imhi3/L7uZ6SvXPOvJf/8Eoq6NdJ9rYxJlGuG35eyjr+TsRwixbOAku7w6QKKoF9hVg/UZsle/j qUAKup5Ce08IabGvtqJZ+PLrtfmz0/oc6C1mU1bK7XMNyUWyS3aUuD0RS89g+B9AZiRzrFOubwt 4puR9I0g6PasAqJp7V18x9ozcgPnmEwSbrZpbRjXCLLMjL+S4NcHn8GKYTHgVdk7MHrfE4ribxq usUTMhimlhh7obO8v8JOIYccrIEQUxlzvUdyDUuKjINZqVgXWWjAQKs4rDQbHfD++9v6nQP121w ja09eQynWDdNNSUXf1pYfKwq4xxD+J+XjiZe3x+zxAdRnx6DfZnqI6ZD/0jy2AnbHNd1IXwtBYw OIt/FpoAdZnl09E+uoc8FdOsip48rn/ZJpqSsIag== X-Google-Smtp-Source: AGHT+IGG/jDsUdC9ibQ+3dpWR2FLY/TlrIh7Vej6kEMkcOQEpt4R1/rKMCT9CFX2SYGxtwXX9fi6fw== X-Received: by 2002:a05:6a00:f98:b0:7e8:43f5:bd4b with SMTP id d2e1a72fcca58-7f6697994f1mr798758b3a.55.1765510498414; Thu, 11 Dec 2025 19:34:58 -0800 (PST) Received: from [192.168.255.10] ([43.132.141.24]) by smtp.gmail.com with ESMTPSA id d2e1a72fcca58-7f4c2773749sm3802960b3a.19.2025.12.11.19.34.52 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 11 Dec 2025 19:34:58 -0800 (PST) Message-ID: Date: Fri, 12 Dec 2025 11:34:50 +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: 7bit 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? > + 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)