The Linux Kernel Mailing List
 help / color / mirror / Atom feed
From: Ingo Molnar <mingo@kernel.org>
To: "H. Peter Anvin" <hpa@zytor.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>,
	Peter Zijlstra <peterz@infradead.org>,
	tglx@kernel.org, mingo@redhat.com, bp@alien8.de,
	Nathan Chancellor <nathan@kernel.org>,
	Calvin Owens <calvin@wbinvd.org>,
	Dave Hansen <dave.hansen@linux.intel.com>,
	x86-ML <x86@kernel.org>, LKML <linux-kernel@vger.kernel.org>
Subject: Re: 8aeb879baf12 - significant system call latency regression, bisected
Date: Wed, 17 Jun 2026 12:05:04 +0200	[thread overview]
Message-ID: <ajJxUBhGTwLD8-fA@gmail.com> (raw)
In-Reply-To: <ajJu5nROLmoINPdR@gmail.com>


* Ingo Molnar <mingo@kernel.org> wrote:

> I'd exclude the L0D, L1DTLB, the RSB and the load/store queues
> as well, because code alignment of a single symbol should have
> a minimal effect on them, which leaves:
>
>  - uOP Queue			    -		   192 entries
>  - uOP Cache (Micro-op Cache)	    -		~5,250 uOPs, ~64 sets x 10-12 way
>  - Reorder Buffer (ROB)		    -		   576 entries
>
> And I think of these the main suspect would be the uOP cache,
> because its (estimated...) ~10-12 deep associativity limit
> of uop-sets may be something this benchmark is hitting on
> Panther Lake?
>
> Could it be that the extra alignment adds +1 to the maximum number
> of uOP cache 'ways' this execution hits in the uOP cache, moving
> it form say 12 (still fits) to 13 (misses) so that this particular
> uOP cache association depth starts trashing? But I'm really just
> guessing wildly here...
>
> ( The extra statistical noise of the regressed figures does suggest
>   some sort of trashing mechanic behind the scenes though, and the
>   regular caches seem large enough to not actually trash for such
>   a cache-hot benchmark. )
>
> Or am I missing something obvious?
>
> Any perf stat uOP related counter measurements might be illuminating.

The relevant uOP cache (Intel DSB) perf stat counters would be:

  starship:~/tip> git grep DSB_ tools/perf/pmu-events/arch/x86/pantherlake/
  tools/perf/pmu-events/arch/x86/pantherlake/frontend.json:        "EventName": "FRONTEND_RETIRED.ANY_DSB_MISS",
  tools/perf/pmu-events/arch/x86/pantherlake/frontend.json:        "EventName": "FRONTEND_RETIRED.DSB_MISS",
  tools/perf/pmu-events/arch/x86/pantherlake/frontend.json:        "EventName": "IDQ.DSB_CYCLES_ANY",
  tools/perf/pmu-events/arch/x86/pantherlake/frontend.json:        "EventName": "IDQ.DSB_CYCLES_OK",
  tools/perf/pmu-events/arch/x86/pantherlake/frontend.json:        "EventName": "IDQ.DSB_UOPS",

In particular FRONTEND_RETIRED.ANY_DSB_MISS and
FRONTEND_RETIRED.DSB_MISS before/after counts?

Thanks,

	Ingo

  reply	other threads:[~2026-06-17 10:05 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-06-13  1:45 8aeb879baf12 - significant system call latency regression, bisected "H. Peter Anvin" (Intel)
2026-06-13  8:59 ` Peter Zijlstra
2026-06-13 20:34   ` H. Peter Anvin
2026-06-13 23:52     ` H. Peter Anvin
2026-06-14  1:50       ` H. Peter Anvin
2026-06-14 18:08         ` Xin Li
2026-06-14 18:31           ` H. Peter Anvin
2026-06-15  0:19         ` H. Peter Anvin
2026-06-15  2:07           ` H. Peter Anvin
2026-06-15  3:41             ` Linus Torvalds
2026-06-15 18:30               ` H. Peter Anvin
2026-06-16  7:12                 ` Peter Zijlstra
2026-06-16  7:38             ` Peter Zijlstra
2026-06-16  7:53             ` Peter Zijlstra
2026-06-16  8:28         ` Peter Zijlstra
2026-06-16  8:46           ` Linus Torvalds
2026-06-16  9:51             ` Ingo Molnar
2026-06-16 17:44               ` H. Peter Anvin
2026-06-17  9:54                 ` Ingo Molnar
2026-06-17 10:05                   ` Ingo Molnar [this message]
2026-06-17 12:37             ` Peter Zijlstra
2026-06-16 13:53           ` David Laight
2026-06-14  2:11       ` Calvin Owens
2026-06-14  2:14         ` Calvin Owens

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=ajJxUBhGTwLD8-fA@gmail.com \
    --to=mingo@kernel.org \
    --cc=bp@alien8.de \
    --cc=calvin@wbinvd.org \
    --cc=dave.hansen@linux.intel.com \
    --cc=hpa@zytor.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@redhat.com \
    --cc=nathan@kernel.org \
    --cc=peterz@infradead.org \
    --cc=tglx@kernel.org \
    --cc=torvalds@linux-foundation.org \
    --cc=x86@kernel.org \
    /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