Linux cgroups development
 help / color / mirror / Atom feed
From: "Luck, Tony" <tony.luck@intel.com>
To: Pasha Tatashin <pasha.tatashin@soleen.com>
Cc: <kees@kernel.org>, <rppt@kernel.org>, <juri.lelli@redhat.com>,
	<nik.borisov@suse.com>, <tglx@kernel.org>, <vschneid@redhat.com>,
	<kprateek.nayak@amd.com>, <vincent.guittot@linaro.org>,
	<bp@alien8.de>, <thorsten.blum@linux.dev>,
	<cgroups@vger.kernel.org>, <david@kernel.org>, <mingo@redhat.com>,
	<akpm@linux-foundation.org>, <linux-mm@kvack.org>,
	<seanjc@google.com>, <ljs@kernel.org>, <zhangguopeng@kylinos.cn>,
	<dietmar.eggemann@arm.com>, <mhocko@suse.com>,
	<vinicius.gomes@intel.com>, <tj@kernel.org>, <vbabka@kernel.org>,
	<linux-kernel@vger.kernel.org>, <peterz@infradead.org>,
	<surenb@google.com>, <hpa@zytor.com>, <x86@kernel.org>,
	<dmatlack@google.com>, <tim.c.chen@linux.intel.com>,
	<kexec@lists.infradead.org>, <pratyush@kernel.org>,
	<dave.hansen@linux.intel.com>, <rostedt@goodmis.org>,
	<gmonaco@redhat.com>, <jgross@suse.com>, <mgorman@suse.de>,
	<graf@amazon.com>, <linux-edac@vger.kernel.org>,
	<liam@infradead.org>, <ridong.chen@linux.dev>,
	<longman@redhat.com>, <bsegall@google.com>
Subject: Re: [PATCH v1 0/8] x86, sched, mm: Speed up CPU hotplug on large systems
Date: Thu, 15 Oct 2026 14:33:57 -0700	[thread overview]
Message-ID: <atFGxagFo50iG6IS@agluck-desk3> (raw)
In-Reply-To: <20261015153331.1872641-1-pasha.tatashin@soleen.com>

On Thu, Oct 15, 2026 at 11:33:23AM -0400, Pasha Tatashin wrote:
>    - Patch 3 bounds cmci_rediscover() on CPU teardown. Currently,
>      cmci_rediscover() broadcasts an IPI via on_each_cpu() to all online
>      CPUs, serializing them on cmci_discover_lock while reading up to 32
>      MCA MSRs. Because any disabled MCA bank is shared at most with an
>      SMT sibling, L2 cluster peer, or die/package peer, probing a single
>      online topology peer via smp_call_function_single() (or returning
>      immediately when no shared banks were orphaned) reduces 479-CPU
>      offline time on Intel from 11.42 s to 9.63 s (-15.7%) and total time
>      from 22.50 s to 20.74 s (-7.8%).

I took this series for a spin on a timy 2-socket Icelake (36 cores, 72
threads per socket). My test was to just offfline/online the 72 logical
CPUs on socket 1, and I saw some good speedups:

	offline: 4.833s -> 3.17s
	online: 6.157s -> 3.796s

I noticed that your cmci_rediscover() improvements mean even better
offline performance if you work from high to low CPU numbers as the
shared banks are assigned to the lowest numbered CPU within the sharing
topology domain. So working from high to low avoids creating as many
orphan banks that then need to find new owners.

	reverse order offline: 2.984s

I haven't looked into the code yet. But the general direction seems
good.

-Tony

      parent reply	other threads:[~2026-10-15 21:34 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-10-15 15:33 [PATCH v1 0/8] x86, sched, mm: Speed up CPU hotplug on large systems Pasha Tatashin
2026-10-15 15:33 ` [PATCH v1 1/8] x86/realmode: Remove unnecessary WBINVD from AP startup trampoline Pasha Tatashin
2026-10-15 15:33 ` [PATCH v1 2/8] x86/smp: Remove unnecessary WBINVD from mwait_play_dead() Pasha Tatashin
2026-10-15 15:33 ` [PATCH v1 3/8] x86/mce/intel: Bound cmci_rediscover() to a single topology peer Pasha Tatashin
2026-10-15 15:33 ` [PATCH v1 4/8] x86/cacheinfo, mtrr: Skip stop_machine rendezvous in cache_ap_online() when MTRRs match Pasha Tatashin
2026-10-15 15:33 ` [PATCH v1 5/8] sched/topology: Avoid redundant O(N^3) group capacity walks and unused allocations in build_sched_domains() Pasha Tatashin
2026-10-15 15:33 ` [PATCH v1 6/8] sched/deadline, topology: Avoid O(N^2) dl_server bandwidth walks during root_domain rebuilds Pasha Tatashin
2026-10-15 15:33 ` [PATCH v1 7/8] sched/topology: Avoid redundant percpu allocations and bitmap walks in build_sched_domains() Pasha Tatashin
2026-10-15 23:17   ` Tim Chen
2026-10-15 15:33 ` [PATCH v1 8/8] mm/vmstat: Avoid redundant per-CPU stat_threshold writes in refresh_zone_stat_thresholds() Pasha Tatashin
2026-10-15 21:33 ` Luck, Tony [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=atFGxagFo50iG6IS@agluck-desk3 \
    --to=tony.luck@intel.com \
    --cc=akpm@linux-foundation.org \
    --cc=bp@alien8.de \
    --cc=bsegall@google.com \
    --cc=cgroups@vger.kernel.org \
    --cc=dave.hansen@linux.intel.com \
    --cc=david@kernel.org \
    --cc=dietmar.eggemann@arm.com \
    --cc=dmatlack@google.com \
    --cc=gmonaco@redhat.com \
    --cc=graf@amazon.com \
    --cc=hpa@zytor.com \
    --cc=jgross@suse.com \
    --cc=juri.lelli@redhat.com \
    --cc=kees@kernel.org \
    --cc=kexec@lists.infradead.org \
    --cc=kprateek.nayak@amd.com \
    --cc=liam@infradead.org \
    --cc=linux-edac@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=ljs@kernel.org \
    --cc=longman@redhat.com \
    --cc=mgorman@suse.de \
    --cc=mhocko@suse.com \
    --cc=mingo@redhat.com \
    --cc=nik.borisov@suse.com \
    --cc=pasha.tatashin@soleen.com \
    --cc=peterz@infradead.org \
    --cc=pratyush@kernel.org \
    --cc=ridong.chen@linux.dev \
    --cc=rostedt@goodmis.org \
    --cc=rppt@kernel.org \
    --cc=seanjc@google.com \
    --cc=surenb@google.com \
    --cc=tglx@kernel.org \
    --cc=thorsten.blum@linux.dev \
    --cc=tim.c.chen@linux.intel.com \
    --cc=tj@kernel.org \
    --cc=vbabka@kernel.org \
    --cc=vincent.guittot@linaro.org \
    --cc=vinicius.gomes@intel.com \
    --cc=vschneid@redhat.com \
    --cc=x86@kernel.org \
    --cc=zhangguopeng@kylinos.cn \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox