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 A0EC5946C for ; Mon, 16 Mar 2026 00:19:03 +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=1773620345; cv=none; b=V/L6xxnuQzUTjFTS0oZ+wZpTu0/lVA8+WxHHmy+iPO+AY3G1OHwdzA1San7lu9VHtAExMeV3EcrXyRV/B+zKMC4sFWZn7Lfts4dwa/dPkkXMxyrd37xb5moNqoOkjK/J8pkcH1R8VXMYmwcDdJKPs/7TR//xrTONZ4sPn7Zd4Mg= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1773620345; c=relaxed/simple; bh=/E9Hpx2P2uGGZUK7W+JE5HzB3KXNY8SNQ9PG4Z9qeNY=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=ijsAaoHzJYL4A4qP46/lGLAcMUTg9Rnz1u3FRauXO8hFzPccxxIgkGBYVq/bXKeil8Teg7FT+UCgsDN/lj5IJJjRVGnLKsIwZ6GriYcAOo2C0T2CBJ3WDPw1JVrRh0Qpp9aD26lf8tuRu5uHdv3qKqRKoY975/Yq6bVyXsvf3KQ= 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 AC53B1477; Sun, 15 Mar 2026 17:18:56 -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 60CF33F7BD; Sun, 15 Mar 2026 17:19:00 -0700 (PDT) Message-ID: <7182d0d5-be42-42bb-8864-189ddedbf534@arm.com> Date: Mon, 16 Mar 2026 01:18:58 +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> From: Dietmar Eggemann Content-Language: en-GB In-Reply-To: <20260312044434.1974-3-kprateek.nayak@amd.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 12.03.26 05:44, K Prateek Nayak wrote: [...] > +/* > + * Calculate an allowed NUMA imbalance such that LLCs do not get > + * imbalanced. > + */ > +static void adjust_numa_imbalance(struct sched_domain *sd_llc) > +{ > + struct sched_domain *parent; > + unsigned int imb_span = 1; > + unsigned int imb = 0; > + unsigned int nr_llcs; > + > + WARN_ON(!(sd_llc->flags & SD_SHARE_LLC)); > + WARN_ON(!sd_llc->parent); > + > + /* > + * For a single LLC per node, allow an > + * imbalance up to 12.5% of the node. This is > + * arbitrary cutoff based two factors -- SMT and > + * memory channels. For SMT-2, the intent is to > + * avoid premature sharing of HT resources but > + * SMT-4 or SMT-8 *may* benefit from a different > + * cutoff. For memory channels, this is a very > + * rough estimate of how many channels may be > + * active and is based on recent CPUs with > + * many cores. > + * > + * For multiple LLCs, allow an imbalance > + * until multiple tasks would share an LLC > + * on one node while LLCs on another node > + * remain idle. This assumes that there are > + * enough logical CPUs per LLC to avoid SMT > + * factors and that there is a correlation > + * between LLCs and memory channels. > + */ > + nr_llcs = sd_llc->parent->span_weight / sd_llc->span_weight; > + if (nr_llcs == 1) > + imb = sd_llc->parent->span_weight >> 3; > + else > + imb = nr_llcs; > + > + imb = max(1U, imb); > + sd_llc->parent->imb_numa_nr = imb; Here you set imb_numa_nr e.g. for PKG ... > + > + /* > + * Set span based on the first NUMA domain. > + * > + * NUMA systems always add a NODE domain before > + * iterating the NUMA domains. Since this is before > + * degeneration, start from sd_llc's parent's > + * parent which is the lowest an SD_NUMA domain can > + * be relative to sd_llc. > + */ > + parent = sd_llc->parent->parent; > + while (parent && !(parent->flags & SD_NUMA)) > + parent = parent->parent; > + > + imb_span = parent ? parent->span_weight : sd_llc->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)); > + > + parent->imb_numa_nr = imb * factor; ... and here again. Shouldn't we only set it for 'if (parent->flags & SD_NUMA)'? Not sure if there are case in which PKG would persist in ... -> MC -> PKG -> NODE -> NUMA -> ... ? Although access to sd->imb_numa_nr seems to be guarded by sd->flags & SD_NUMA. > + parent = parent->parent; > + } > +} > + [...]