From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 5BA49350A24 for ; Fri, 6 Feb 2026 09:38:52 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=170.10.133.124 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1770370732; cv=none; b=pGfutQ7qqskxEL2+9uBbMco/DcbZu0LjbW6vOek0EV3szgAZ+2Dg43luY32Zn0FgyOtrC67YhKP8SGLt9V48DaGam9ySFXl6HMCG3enytHNGRM2HNC43zN1Y+nqsOvGzT/EEemnCCZdeaneHSH8rMr/JB26TeLuWgqa2+eR6sK0= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1770370732; c=relaxed/simple; bh=xKy3QyfoB3xbqJibLVl7N/xP8utdtdNqLRoQAoE/Uh0=; h=From:To:Cc:Subject:In-Reply-To:References:Date:Message-ID: MIME-Version:Content-Type; b=UlBXtlLf7tq5DbOZX9JwTdLEHnZx9mqrb3lGqxHW2pRJzRPxKNctPWb8IbmLYkelc9ECOeP49IN1BM5dGD8gN34VAXjFgwcnZJVI9cMxJZamu8cQ331XVfcKMZRn9kaFR+Vz5J1Bf9qu6xSzZHvyRvYFHNUX96tzgg3OtjTLblc= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=redhat.com; spf=pass smtp.mailfrom=redhat.com; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b=QVHr//hX; dkim=pass (2048-bit key) header.d=redhat.com header.i=@redhat.com header.b=f3Q27sOA; arc=none smtp.client-ip=170.10.133.124 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=redhat.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=redhat.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b="QVHr//hX"; dkim=pass (2048-bit key) header.d=redhat.com header.i=@redhat.com header.b="f3Q27sOA" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1770370731; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=97G7lVgYbtQu5twcwDu/LWl/qFY7ch6wkErZ5ko77f4=; b=QVHr//hXNscklwSa5ZEFeE9ULFOS64VO0EKVp2QVzzM4Avw0exLDCrCvmITYhR4vpaMv1z YgfZgPReuzqyFfIFFVDyTbYv03OqNvhjL7F6nAfV60FwNNPPLGQZDDO/Sz5PrKtcsA5tGX B5rrV2fgtJ/Mpoe3OuoJ/MquyJoZlxo= Received: from mail-wm1-f69.google.com (mail-wm1-f69.google.com [209.85.128.69]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-152-IBvPhhclO3KADLzY0GRYtg-1; Fri, 06 Feb 2026 04:38:50 -0500 X-MC-Unique: IBvPhhclO3KADLzY0GRYtg-1 X-Mimecast-MFC-AGG-ID: IBvPhhclO3KADLzY0GRYtg_1770370729 Received: by mail-wm1-f69.google.com with SMTP id 5b1f17b1804b1-47ee056e5cfso17753005e9.1 for ; Fri, 06 Feb 2026 01:38:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=google; t=1770370729; x=1770975529; darn=vger.kernel.org; h=mime-version:message-id:date:references:in-reply-to:subject:cc:to :from:from:to:cc:subject:date:message-id:reply-to; bh=97G7lVgYbtQu5twcwDu/LWl/qFY7ch6wkErZ5ko77f4=; b=f3Q27sOAHjayMZhEQlsUauNGK++HA+jS2gZ1dkR9IwRFOttnD1qDRoln/2k9PIDT0k rTRx2Gq6JbHVMf9GGLqhhFoiua4yWe5dtnFaD2Cmzs1ylbB1XpQNPYqQinOEHP7476D7 POZlyT71l1dxpMP1ogeT09y26HSMIiJ4f+N7XdyQKq1MYw6SftaFoEIfSE2nWGQjoX3h eTgP5UlAVnVJ55gtu5Pazax0rGjmx/DJ3knS5per06OAZvV3b6DYT6yB/QxNbtLcDR7z jr2YHADPeMuKb7R1gLNU+Az6rInxFMXBJDBkTIXz9PYozBDgCcBI4BWMOa2rYTTg+XKi Gw/g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1770370729; x=1770975529; h=mime-version:message-id:date:references:in-reply-to:subject:cc:to :from:x-gm-gg:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=97G7lVgYbtQu5twcwDu/LWl/qFY7ch6wkErZ5ko77f4=; b=Dnk4To+soDPWxR5ogASih7i8Anw/30S2XP4GWyU3N8nw5lLvTjtv+Ie286dJSDYXXe t9R07kixfyupjYfZd5ECXgda3dC925aa2Imb3nhaPZ6rxZI8DvVwXZQHjx1++5D5N7s2 htZSCpOuN7uGu16CYfkcclpXSRacQToNu5CuUaLZCrlk46OaXk5xZG4NVBwAO8Z7H1IP wQOTrTAbYjZDCZTo+40mjtlIuWiFbGa1cfpuqtvLgZNI620Qbm5TWK+ULxHOPvQhOZXM J5zN6nlhq74xEtUMJVzkfGzST/5npbwsO3yNE8+ca56Y1ggPUIJxUlIjwzDK/qSRxV/h MlgQ== X-Forwarded-Encrypted: i=1; AJvYcCWd2MjHCOWMUhuIRPz9ufHB0ai6cH+kUNHaBjI87Eeu49++k4L/6jscTTFn/zasqOScC0B2Bbj5H2ZmQ5s=@vger.kernel.org X-Gm-Message-State: AOJu0YzA+ReCofj8dptYEKthzlrpvwNRrjI7d5XCrA8mg6tGxsFoybXa F94wTUI/j8vwryx9/WZvZJrABu96vRi9Bh02cSGQTq4QUuLTtXyv3PajZgNPsqbdqjKfFDulwW1 vDFf9VtM2PKyplYtUEoycR8IN+AD3DDMA8Cm8aSij2cRJSZIw7wd0X7j1bqXr6DPriA== X-Gm-Gg: AZuq6aJOhNMYzve8Ww7EqkxMtte5ao71VABJEVc9cyehGVnJ/hUfx06693EAJsRtYWd 2jm53R+9mGPe+DqNOgUId56cE5UNVSkC9wW/Fq/GKqUfYq+6oKrZsUoii7ddXdvn30Rke2Zleg3 Enslc62IuwoBwuj8nzz26y2bCd8Or0uC3Fg78KoIBG80j2fyPmKUV9n/V6+R1B7oofLbzRXVrgA sRVr4KRnD1WeLh7dvxsXnPzZbV7R23yIXWFPvPs5M1G9/zP7TtYq6G/pdqEq2JlnmW5U6CTNHtD AsDpa260J8VLrGXMLVTFX6scTwSmwHPkCxhMdUFcV9qS72vr3CnG2MQ9Ht27fmQyczTMfIkcfQ5 R/p5FctEVsT8GIgxFdqdtrJ9wA8Q0HLceZu4oEuYg4+A6G3Okj4tTpk+nBCZiJtXAbTRAW94= X-Received: by 2002:a05:600c:3b23:b0:480:4be7:4f53 with SMTP id 5b1f17b1804b1-4832021da3dmr32192605e9.31.1770370728745; Fri, 06 Feb 2026 01:38:48 -0800 (PST) X-Received: by 2002:a05:600c:3b23:b0:480:4be7:4f53 with SMTP id 5b1f17b1804b1-4832021da3dmr32192185e9.31.1770370728192; Fri, 06 Feb 2026 01:38:48 -0800 (PST) Received: from vschneid-thinkpadt14sgen2i.remote.csb (213-44-135-146.abo.bbox.fr. [213.44.135.146]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-48320719bf4sm38851815e9.10.2026.02.06.01.38.47 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 06 Feb 2026 01:38:47 -0800 (PST) From: Valentin Schneider To: K Prateek Nayak , Ingo Molnar , Peter Zijlstra , Juri Lelli , Vincent Guittot , linux-kernel@vger.kernel.org Cc: Dietmar Eggemann , Steven Rostedt , Ben Segall , Mel Gorman , Chen Yu , Shrikanth Hegde , "Gautham R. Shenoy" Subject: Re: [PATCH v3 3/8] sched/topology: Switch to assigning "sd->shared" from s_data In-Reply-To: <47c5f6eb-1622-4aeb-b9ff-6ebf63cc8097@amd.com> References: <20260120113246.27987-1-kprateek.nayak@amd.com> <20260120113246.27987-4-kprateek.nayak@amd.com> <47c5f6eb-1622-4aeb-b9ff-6ebf63cc8097@amd.com> Date: Fri, 06 Feb 2026 10:38:46 +0100 Message-ID: Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain On 06/02/26 10:50, K Prateek Nayak wrote: > Hello Valentin, > > On 2/5/2026 10:23 PM, Valentin Schneider wrote: >> On 20/01/26 11:32, K Prateek Nayak wrote: >>> @@ -2655,8 +2655,19 @@ build_sched_domains(const struct cpumask *cpu_map, struct sched_domain_attr *att >>> unsigned int imb_span = 1; >>> >>> for (sd = *per_cpu_ptr(d.sd, i); sd; sd = sd->parent) { >>> + struct sched_domain *parent = sd->parent; >>> struct sched_domain *child = sd->child; >>> >>> + /* Attach sd->shared to the topmost SD_SHARE_LLC domain. */ >>> + if ((sd->flags & SD_SHARE_LLC) && >>> + (!parent || !(parent->flags & SD_SHARE_LLC))) { >>> + int llc_id = cpumask_first(sched_domain_span(sd)); >>> + >>> + sd->shared = *per_cpu_ptr(d.sds, llc_id); >>> + atomic_set(&sd->shared->nr_busy_cpus, sd->span_weight); >>> + atomic_inc(&sd->shared->ref); >>> + } >>> + >> >> We now have two if's looking for the highest_flag_domain(i, SD_SHARE_LLC), >> but given this needs to write the sd->imb_numa_nr for every SD I couldn't >> factorize this into something that looked sane :( > > Yeah! The "imb_numa_nr" cares about the "sd_llc" *after* we've crossed > it and "sd->shared" assignment cares when we are *at* the sd_llc. > > Since we have to assign the "sd->shared" before claim_allocations(), > I couldn't find a better spot to assign it. > > That said, "imb_numa_nr" calculation can be modified to use the "sd_llc" > and its "parent". I'll let you be the judge of whether the following is > better or worse ;-) > > (Only build tested) > > diff --git a/kernel/sched/topology.c b/kernel/sched/topology.c > index ac268da91778..e98bb812de35 100644 > --- a/kernel/sched/topology.c > +++ b/kernel/sched/topology.c > @@ -2614,13 +2614,23 @@ build_sched_domains(const struct cpumask *cpu_map, struct sched_domain_attr *att > unsigned int imb_span = 1; > > for (sd = *per_cpu_ptr(d.sd, i); sd; sd = sd->parent) { > - struct sched_domain *child = sd->child; > + struct sched_domain *parent = sd->parent; > > - if (!(sd->flags & SD_SHARE_LLC) && child && > - (child->flags & SD_SHARE_LLC)) { > - struct sched_domain __rcu *top_p; > + /* Topmost SD_SHARE_LLC domain. */ > + if ((sd->flags & SD_SHARE_LLC) && > + (!parent || !(parent->flags & SD_SHARE_LLC))) { > + int sd_id = cpumask_first(sched_domain_span(sd)); > + struct sched_domain *top_p; > unsigned int nr_llcs; > > + sd->shared = *per_cpu_ptr(d.sds, sd_id); > + atomic_set(&sd->shared->nr_busy_cpus, sd->span_weight); > + atomic_inc(&sd->shared->ref); > + > + /* No SD_NUMA domains. */ > + if (!parent) > + break; > + AIUI we currently write sd->imb_numa_nr for all SD's, but it's only useful for the SD_NUMA ones... How about the lightly tested: --- diff --git a/kernel/sched/topology.c b/kernel/sched/topology.c index afb2c26efb4e5..03db45658f6bd 100644 --- a/kernel/sched/topology.c +++ b/kernel/sched/topology.c @@ -2575,6 +2575,51 @@ static bool topology_span_sane(const struct cpumask *cpu_map) return true; } +static inline void adjust_numa_imbalance(struct sched_domain *sd_llc, + unsigned int *imb, unsigned int *imb_span) +{ + /* + * 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. + */ + struct sched_domain *top_p; + unsigned int nr_llcs; + + WARN_ON(!(sd_llc->flags & SD_SHARE_LLC)); + WARN_ON(!sd_llc->parent); + + 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; + + /* Set span based on the first NUMA domain. */ + top_p = sd_llc->parent->parent; + while (top_p && !(top_p->flags & SD_NUMA)) { + top_p = top_p->parent; + } + *imb_span = top_p ? top_p->span_weight : sd_llc->parent->span_weight; +} + /* * Build sched domains for a given set of CPUs and attach the sched domains * to the individual CPUs @@ -2640,63 +2685,30 @@ build_sched_domains(const struct cpumask *cpu_map, struct sched_domain_attr *att unsigned int imb = 0; unsigned int imb_span = 1; - for (sd = *per_cpu_ptr(d.sd, i); sd; sd = sd->parent) { - struct sched_domain *parent = sd->parent; - - /* Topmost SD_SHARE_LLC domain. */ - if ((sd->flags & SD_SHARE_LLC) && - (!parent || !(parent->flags & SD_SHARE_LLC))) { - int sd_id = cpumask_first(sched_domain_span(sd)); - struct sched_domain *top_p; - unsigned int nr_llcs; - - sd->shared = *per_cpu_ptr(d.sds, sd_id); - atomic_set(&sd->shared->nr_busy_cpus, sd->span_weight); - atomic_inc(&sd->shared->ref); - - /* No SD_NUMA domains. */ - if (!parent) - break; - - /* - * 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 = parent->span_weight / sd->span_weight; - if (nr_llcs == 1) - imb = sd->span_weight >> 3; - else - imb = nr_llcs; - imb = max(1U, imb); - sd->imb_numa_nr = imb; - - /* Set span based on the first NUMA domain. */ - top_p = parent; - while (top_p && !(top_p->flags & SD_NUMA)) { - top_p = top_p->parent; - } - imb_span = top_p ? top_p->span_weight : parent->span_weight; - } else { - int factor = max(1U, (sd->span_weight / imb_span)); + sd = *per_cpu_ptr(d.sd, i); + /* First, find the topmost SD_SHARE_LLC domain */ + while (sd && sd->parent && (sd->parent->flags & SD_SHARE_LLC)) + sd = sd->parent; - sd->imb_numa_nr = imb * factor; - } + if (sd->flags & SD_SHARE_LLC) { + int sd_id = cpumask_first(sched_domain_span(sd)); + + sd->shared = *per_cpu_ptr(d.sds, sd_id); + atomic_set(&sd->shared->nr_busy_cpus, sd->span_weight); + atomic_inc(&sd->shared->ref); + } + + /* Special case the first parent of the topmost SD_SHARE_LLC domain. */ + if ((sd->flags & SD_SHARE_LLC) && sd->parent) { + adjust_numa_imbalance(sd, &imb, &imb_span); + sd = sd->parent->parent; + } + + /* Update the upper remainder of the topology */ + while (sd) { + int factor = max(1U, (sd->span_weight / imb_span)); + sd->imb_numa_nr = imb * factor; + sd = sd->parent; } }