From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by smtp.subspace.kernel.org (Postfix) with ESMTP id 60AD4372EC3 for ; Mon, 16 Mar 2026 08:25:02 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=217.140.110.172 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1773649505; cv=none; b=sO3cnU6J9gix83AmJNZKuM2bpU2y4N/dw1i3GOM+EktUOqwbkU2yi0m2h1b4Y4/FccQ6eOm8uFYNEs8J5v3oQqi+H3NM5CPhbEUN2Aqu3ChB70u2td10F2CjuZFEFgu22roT38qbeG1CVwXDpQ1jaJuHAFEyAVMbO8uijORXTlI= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1773649505; c=relaxed/simple; bh=TFWG7msx2CDEbDfgW+Sv9YJgEtQAsktAbm3hxTOiq74=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=tYeB+qUdat0HMvcpOxLKjCMkQ2kTchZ1lfPEjSEFzXzf57zz6V7KcWu+78Z/UNBIw7BDCUaELRghr4Xd04H5QCqomJw1AcRa9D1XaGZ+PmKNilG7UJ8c9h9g/onhfW3Rm31FA7LCAX9nrQ6/sD+yjx7lIIxUGqWcB3sxSlPR9jo= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=arm.com; spf=pass smtp.mailfrom=arm.com; arc=none smtp.client-ip=217.140.110.172 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=arm.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=arm.com Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 5F3731477; Mon, 16 Mar 2026 01:24:55 -0700 (PDT) Received: from [192.168.178.6] (usa-sjc-mx-foss1.foss.arm.com [172.31.20.19]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 19EBE3F73B; Mon, 16 Mar 2026 01:24:58 -0700 (PDT) Message-ID: Date: Mon, 16 Mar 2026 09:24:57 +0100 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 v4 2/9] sched/topology: Extract "imb_numa_nr" calculation into a separate helper To: K Prateek Nayak , Ingo Molnar , Peter Zijlstra , Juri Lelli , Vincent Guittot , Valentin Schneider , linux-kernel@vger.kernel.org Cc: Steven Rostedt , Ben Segall , Mel Gorman , Chen Yu , Shrikanth Hegde , Li Chen , "Gautham R. Shenoy" References: <20260312044434.1974-1-kprateek.nayak@amd.com> <20260312044434.1974-3-kprateek.nayak@amd.com> <7182d0d5-be42-42bb-8864-189ddedbf534@arm.com> Content-Language: en-GB From: Dietmar Eggemann In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Hi Prateek, On 16.03.26 04:41, K Prateek Nayak wrote: > Hello Dietmar, > > On 3/16/2026 5:48 AM, Dietmar Eggemann wrote: [...] > Indeed! "imb_numa_nr" only makes sense when looking at NUMA domains > and having it assigned to 1 for lower domains is harmless > (but wasteful indeed). I'm 99% sure we can simply do: > > (Only build tested) > > diff --git a/kernel/sched/topology.c b/kernel/sched/topology.c > index 43150591914b..e9068a809dbc 100644 > --- a/kernel/sched/topology.c > +++ b/kernel/sched/topology.c > @@ -2623,9 +2623,6 @@ static void adjust_numa_imbalance(struct sched_domain *sd_llc) > else > imb = nr_llcs; > > - imb = max(1U, imb); > - sd_llc->parent->imb_numa_nr = imb; > - > /* > * Set span based on the first NUMA domain. > * > @@ -2639,10 +2636,14 @@ static void adjust_numa_imbalance(struct sched_domain *sd_llc) > while (parent && !(parent->flags & SD_NUMA)) > parent = parent->parent; > > - imb_span = parent ? parent->span_weight : sd_llc->parent->span_weight; > + /* No NUMA domain to adjust imbalance for! */ > + if (!parent) > + return; > + > + imb = max(1U, imb); > + imb_span = parent->span_weight; > > /* Update the upper remainder of the topology */ > - parent = sd_llc->parent; > while (parent) { > int factor = max(1U, (parent->span_weight / imb_span)); > > --- > > If we have NUMA domains, we definitely have NODE and NODE sets neither > SD_SHARE_LLC, nor SD_NUMA so likely sd->parent is PKG / NODE domain and > NUMA has to start at sd->parent->parent and it has to break at the first > SD_NUMA domains. > > If it doesn't exist, we don't have any NUMA domains and nothing to worry > about, and if we do, the final loop will adjust the NUMA imbalance. > > Thoughts? Again, this commit was kept 1:1 with the previous loop but we > can always improve :-) Ah, I see! This would work, IMHO. Tested on qemu-system-aarch64 w/ -smp 8,sockets=2,clusters=2,cores=2,threads=1 Are you aware of a setup in which PKG would survive between MC and lowest NUMA?