From: Dave Hansen <dave.hansen@intel.com>
To: Mike Rapoport <rppt@kernel.org>
Cc: "Jürgen Groß" <jgross@suse.com>,
"Dave Hansen" <dave.hansen@linux.intel.com>,
"Andy Lutomirski" <luto@kernel.org>,
"Borislav Petkov" <bp@alien8.de>,
"Ingo Molnar" <mingo@kernel.org>,
"Ingo Molnar" <mingo@redhat.com>,
"H. Peter Anvin" <hpa@zytor.com>,
"Peter Zijlstra" <peterz@infradead.org>,
"Thomas Gleixner" <tglx@kernel.org>,
x86@kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] x86/mm/pat: fix effective RW computation in lookup_address_in_pgd_attr()
Date: Thu, 16 Jul 2026 06:50:07 -0700 [thread overview]
Message-ID: <adecc483-ca7e-4c03-ab35-88a0400a4867@intel.com> (raw)
In-Reply-To: <aljgOjRTV9xxRubI@kernel.org>
On 7/16/26 06:44, Mike Rapoport wrote:
>> What does "slower" mean here?
>
> I've seen ~2% difference per set_memory call in instrumented cpa-test.
>
>> Does it matter in _practice_? Does it measurably slow down something an
>> end user might see?
> Yes, if a user is loading/unloading a BPF program in a tight loop 🙂
IMNHO, it may be worth optimizing if you can measure the difference in
BPF program load times (even in a tight loop).
But if set_memory() is the only thing you can measure a delta in, I'm
less convinced.
It's really sounding to me like we should do the simplest thing for a
bug fix and then arm wrestle later about how to micro-optimize the sucker.
prev parent reply other threads:[~2026-07-16 13:50 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-07-16 8:10 [PATCH] x86/mm/pat: fix effective RW computation in lookup_address_in_pgd_attr() Mike Rapoport (Microsoft)
2026-07-16 8:37 ` Jürgen Groß
2026-07-16 8:46 ` Juergen Gross
2026-07-16 9:18 ` Mike Rapoport
2026-07-16 12:35 ` David Laight
2026-07-16 12:46 ` Juergen Gross
2026-07-16 12:49 ` David Laight
2026-07-16 12:55 ` Jürgen Groß
2026-07-16 13:27 ` Dave Hansen
2026-07-16 13:44 ` Mike Rapoport
2026-07-16 13:50 ` Dave Hansen [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=adecc483-ca7e-4c03-ab35-88a0400a4867@intel.com \
--to=dave.hansen@intel.com \
--cc=bp@alien8.de \
--cc=dave.hansen@linux.intel.com \
--cc=hpa@zytor.com \
--cc=jgross@suse.com \
--cc=linux-kernel@vger.kernel.org \
--cc=luto@kernel.org \
--cc=mingo@kernel.org \
--cc=mingo@redhat.com \
--cc=peterz@infradead.org \
--cc=rppt@kernel.org \
--cc=tglx@kernel.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.