From: Peter Zijlstra <peterz@infradead.org>
To: Colton Lewis <coltonlewis@google.com>
Cc: kvm@vger.kernel.org, oliver.upton@linux.dev, seanjc@google.com,
mingo@redhat.com, acme@kernel.org, namhyung@kernel.org,
mark.rutland@arm.com, alexander.shishkin@linux.intel.com,
jolsa@kernel.org, irogers@google.com, adrian.hunter@intel.com,
kan.liang@linux.intel.com, will@kernel.org,
linux@armlinux.org.uk, catalin.marinas@arm.com,
mpe@ellerman.id.au, npiggin@gmail.com,
christophe.leroy@csgroup.eu, naveen@kernel.org,
hca@linux.ibm.com, gor@linux.ibm.com, agordeev@linux.ibm.com,
borntraeger@linux.ibm.com, svens@linux.ibm.com,
tglx@linutronix.de, bp@alien8.de, dave.hansen@linux.intel.com,
x86@kernel.org, hpa@zytor.com, linux-perf-users@vger.kernel.org,
linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
linuxppc-dev@lists.ozlabs.org, linux-s390@vger.kernel.org
Subject: Re: [PATCH v7 4/5] x86: perf: Refactor misc flag assignments
Date: Fri, 8 Nov 2024 20:20:43 +0100 [thread overview]
Message-ID: <20241108192043.GA22801@noisy.programming.kicks-ass.net> (raw)
In-Reply-To: <gsntbjypft37.fsf@coltonlewis-kvm.c.googlers.com>
On Fri, Nov 08, 2024 at 07:01:16PM +0000, Colton Lewis wrote:
> Peter Zijlstra <peterz@infradead.org> writes:
>
> > On Thu, Nov 07, 2024 at 07:03:35PM +0000, Colton Lewis wrote:
> > > Break the assignment logic for misc flags into their own respective
> > > functions to reduce the complexity of the nested logic.
>
> > > Signed-off-by: Colton Lewis <coltonlewis@google.com>
> > > Reviewed-by: Oliver Upton <oliver.upton@linux.dev>
> > > ---
> > > arch/x86/events/core.c | 32 +++++++++++++++++++++++--------
> > > arch/x86/include/asm/perf_event.h | 2 ++
> > > 2 files changed, 26 insertions(+), 8 deletions(-)
>
> > > diff --git a/arch/x86/events/core.c b/arch/x86/events/core.c
> > > index d19e939f3998..9fdc5fa22c66 100644
> > > --- a/arch/x86/events/core.c
> > > +++ b/arch/x86/events/core.c
> > > @@ -3011,16 +3011,35 @@ unsigned long
> > > perf_arch_instruction_pointer(struct pt_regs *regs)
> > > return regs->ip + code_segment_base(regs);
> > > }
>
> > > +static unsigned long common_misc_flags(struct pt_regs *regs)
> > > +{
> > > + if (regs->flags & PERF_EFLAGS_EXACT)
> > > + return PERF_RECORD_MISC_EXACT_IP;
> > > +
> > > + return 0;
> > > +}
> > > +
> > > +unsigned long perf_arch_guest_misc_flags(struct pt_regs *regs)
> > > +{
> > > + unsigned long guest_state = perf_guest_state();
> > > + unsigned long flags = common_misc_flags(regs);
>
> > This is double common_misc and makes no sense
>
> I'm confused what you mean. Are you referring to starting with
> common_misc_flags in both perf_arch_misc_flags and
> perf_arch_guest_misc_flags so possibly the common_msic_flags are set
> twice?
>
> That seems like a good thing that common flags are set wherever they
> apply. You can't guarantee where perf_arch_guest_misc_flags may be
> called in the future.
I got confused by perf_arch_misc_flags() calling common_misc_flags()
twice. It is in fact worse, because afaict all of
perf_arch_guest_misc_flags() is 'common'.
Isn't the below more or less what you want?
static unsigned long misc_flags(struct pt_regs *regs)
{
unsigned long flags = 0;
if (regs->flags & PERF_EFLAGS_EXACT)
flags |= PERF_RECORD_MISC_EXACT_IP;
return flags;
}
static unsigned long native_flags(struct pt_regs *regs)
{
unsigned long flags = 0;
if (user_mode(regs))
flags |= PERF_RECORD_MISC_USER;
else
flags |= PERF_RECORD_MISC_KERNEL;
return flags;
}
static unsigned long guest_flags(struct pt_regs *regs)
{
unsigned long guest_state = perf_guest_state();
unsigned long flags = 0;
if (guest_state & PERF_GUEST_ACTIVE) {
if (guest_state & PERF_GUEST_USER)
flags |= PERF_RECORD_MISC_GUEST_USER;
else
flags |= PERF_RECORD_MISC_GUEST_KERNEL;
}
return flags;
}
unsigned long perf_arch_guest_misc_flags(struct pt_regs *regs)
{
unsigned long flags;
flags = misc_flags(regs);
flags |= guest_flags(regs);
return flags;
}
unsigned long perf_arch_misc_flags(struct pt_regs *regs)
{
unsigned long flags;
unsigned long guest;
flags = misc_flags(regs);
guest = guest_flags(regs);
if (guest)
flags |= guest;
else
flags |= native_flags(regs);
return flags;
}
Note how both perf_arch*() functions end up calling both misc and guest.
next prev parent reply other threads:[~2024-11-08 19:21 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-11-07 19:03 [PATCH v7 0/5] Correct perf sampling with Guest VMs Colton Lewis
2024-11-07 19:03 ` [PATCH v7 1/5] arm: perf: Drop unused functions Colton Lewis
2024-11-07 19:03 ` [PATCH v7 2/5] perf: Hoist perf_instruction_pointer() and perf_misc_flags() Colton Lewis
2024-11-07 19:39 ` Liang, Kan
2024-11-07 19:03 ` [PATCH v7 3/5] powerpc: perf: Use perf_arch_instruction_pointer() Colton Lewis
2024-11-07 19:03 ` [PATCH v7 4/5] x86: perf: Refactor misc flag assignments Colton Lewis
2024-11-07 19:40 ` Liang, Kan
2024-11-08 15:34 ` Peter Zijlstra
2024-11-08 19:01 ` Colton Lewis
2024-11-08 19:20 ` Peter Zijlstra [this message]
2024-11-08 19:32 ` Peter Zijlstra
2024-11-13 18:24 ` Colton Lewis
2024-11-13 18:39 ` Colton Lewis
2024-11-07 19:03 ` [PATCH v7 5/5] perf: Correct perf sampling with guest VMs Colton Lewis
2024-11-07 19:46 ` Liang, Kan
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=20241108192043.GA22801@noisy.programming.kicks-ass.net \
--to=peterz@infradead.org \
--cc=acme@kernel.org \
--cc=adrian.hunter@intel.com \
--cc=agordeev@linux.ibm.com \
--cc=alexander.shishkin@linux.intel.com \
--cc=borntraeger@linux.ibm.com \
--cc=bp@alien8.de \
--cc=catalin.marinas@arm.com \
--cc=christophe.leroy@csgroup.eu \
--cc=coltonlewis@google.com \
--cc=dave.hansen@linux.intel.com \
--cc=gor@linux.ibm.com \
--cc=hca@linux.ibm.com \
--cc=hpa@zytor.com \
--cc=irogers@google.com \
--cc=jolsa@kernel.org \
--cc=kan.liang@linux.intel.com \
--cc=kvm@vger.kernel.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-perf-users@vger.kernel.org \
--cc=linux-s390@vger.kernel.org \
--cc=linux@armlinux.org.uk \
--cc=linuxppc-dev@lists.ozlabs.org \
--cc=mark.rutland@arm.com \
--cc=mingo@redhat.com \
--cc=mpe@ellerman.id.au \
--cc=namhyung@kernel.org \
--cc=naveen@kernel.org \
--cc=npiggin@gmail.com \
--cc=oliver.upton@linux.dev \
--cc=seanjc@google.com \
--cc=svens@linux.ibm.com \
--cc=tglx@linutronix.de \
--cc=will@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).