[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <BYAPR21MB1688853D01CABA74B51DA841D77E9@BYAPR21MB1688.namprd21.prod.outlook.com>
Date: Wed, 17 May 2023 02:26:35 +0000
From: "Michael Kelley (LINUX)" <mikelley@...rosoft.com>
To: Peter Zijlstra <peterz@...radead.org>,
"bigeasy@...utronix.de" <bigeasy@...utronix.de>
CC: Mark Rutland <Mark.Rutland@....com>,
"maz@...nel.org" <maz@...nel.org>,
"catalin.marinas@....com" <catalin.marinas@....com>,
"will@...nel.org" <will@...nel.org>,
"chenhuacai@...nel.org" <chenhuacai@...nel.org>,
"kernel@...0n.name" <kernel@...0n.name>,
"hca@...ux.ibm.com" <hca@...ux.ibm.com>,
"gor@...ux.ibm.com" <gor@...ux.ibm.com>,
"agordeev@...ux.ibm.com" <agordeev@...ux.ibm.com>,
"borntraeger@...ux.ibm.com" <borntraeger@...ux.ibm.com>,
"svens@...ux.ibm.com" <svens@...ux.ibm.com>,
"pbonzini@...hat.com" <pbonzini@...hat.com>,
"wanpengli@...cent.com" <wanpengli@...cent.com>,
"vkuznets@...hat.com" <vkuznets@...hat.com>,
"tglx@...utronix.de" <tglx@...utronix.de>,
"mingo@...hat.com" <mingo@...hat.com>,
"bp@...en8.de" <bp@...en8.de>,
"dave.hansen@...ux.intel.com" <dave.hansen@...ux.intel.com>,
"x86@...nel.org" <x86@...nel.org>, "hpa@...or.com" <hpa@...or.com>,
"jgross@...e.com" <jgross@...e.com>,
"boris.ostrovsky@...cle.com" <boris.ostrovsky@...cle.com>,
"daniel.lezcano@...aro.org" <daniel.lezcano@...aro.org>,
KY Srinivasan <kys@...rosoft.com>,
Haiyang Zhang <haiyangz@...rosoft.com>,
"wei.liu@...nel.org" <wei.liu@...nel.org>,
Dexuan Cui <decui@...rosoft.com>,
"rafael@...nel.org" <rafael@...nel.org>,
"longman@...hat.com" <longman@...hat.com>,
"boqun.feng@...il.com" <boqun.feng@...il.com>,
"pmladek@...e.com" <pmladek@...e.com>,
"senozhatsky@...omium.org" <senozhatsky@...omium.org>,
"rostedt@...dmis.org" <rostedt@...dmis.org>,
"john.ogness@...utronix.de" <john.ogness@...utronix.de>,
"juri.lelli@...hat.com" <juri.lelli@...hat.com>,
"vincent.guittot@...aro.org" <vincent.guittot@...aro.org>,
"dietmar.eggemann@....com" <dietmar.eggemann@....com>,
"bsegall@...gle.com" <bsegall@...gle.com>,
"mgorman@...e.de" <mgorman@...e.de>,
"bristot@...hat.com" <bristot@...hat.com>,
"vschneid@...hat.com" <vschneid@...hat.com>,
"jstultz@...gle.com" <jstultz@...gle.com>,
"sboyd@...nel.org" <sboyd@...nel.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"loongarch@...ts.linux.dev" <loongarch@...ts.linux.dev>,
"linux-s390@...r.kernel.org" <linux-s390@...r.kernel.org>,
"kvm@...r.kernel.org" <kvm@...r.kernel.org>,
"linux-hyperv@...r.kernel.org" <linux-hyperv@...r.kernel.org>,
"linux-pm@...r.kernel.org" <linux-pm@...r.kernel.org>
Subject: RE: [RFC][PATCH 7/9] x86/tsc: Provide sched_clock_noinstr()
From: Peter Zijlstra <peterz@...radead.org> Sent: Monday, May 8, 2023 2:44 PM
>
> On Mon, May 08, 2023 at 11:19:58PM +0200, Peter Zijlstra wrote:
>
> > --- a/drivers/clocksource/hyperv_timer.c
> > +++ b/drivers/clocksource/hyperv_timer.c
> > @@ -408,9 +408,9 @@ static u64 notrace read_hv_clock_tsc_cs(
> > return read_hv_clock_tsc();
> > }
> >
> > -static u64 notrace read_hv_sched_clock_tsc(void)
> > +static u64 noinstr read_hv_sched_clock_tsc(void)
> > {
> > - return (read_hv_clock_tsc() - hv_sched_clock_offset) *
> > + return (hv_read_tsc_page(hv_get_tsc_page()) - hv_sched_clock_offset) *
> > (NSEC_PER_SEC / HV_CLOCK_HZ);
> > }
> >
> > --- a/include/clocksource/hyperv_timer.h
> > +++ b/include/clocksource/hyperv_timer.h
> > @@ -38,7 +38,7 @@ extern void hv_remap_tsc_clocksource(voi
> > extern unsigned long hv_get_tsc_pfn(void);
> > extern struct ms_hyperv_tsc_page *hv_get_tsc_page(void);
> >
> > -static inline notrace u64
> > +static __always_inline notrace u64
> > hv_read_tsc_page_tsc(const struct ms_hyperv_tsc_page *tsc_pg, u64 *cur_tsc)
> > {
> > u64 scale, offset;
> > @@ -85,7 +85,7 @@ hv_read_tsc_page_tsc(const struct ms_hyp
> > return mul_u64_u64_shr(*cur_tsc, scale, 64) + offset;
> > }
> >
> > -static inline notrace u64
> > +static __always_inline notrace u64
> > hv_read_tsc_page(const struct ms_hyperv_tsc_page *tsc_pg)
> > {
> > u64 cur_tsc;
>
> Hyper-V folks!
>
> While reviewing all this I found the following 'gem':
>
> hv_init_clocksource()
> hv_setup_sched_clock()
> paravirt_set_sched_clock(read_hv_sched_clock_msr)
>
> read_hv_sched_clock_msr() [notrace]
> read_hv_clock_msr() [notrace]
> hv_get_register() *traced*
> hv_get_non_nested_register() ...
> hv_ghcb_msr_read()
> WARN_ON(in_nmi())
> ...
> local_irq_save()
>
>
> Note that:
>
> a) sched_clock() is used in NMI context a *LOT*
> b) sched_clock() is notrace (or even noinstr with these patches)
> and local_irq_save() implies tracing
>
>
> Can you pretty please:
>
> 1) delete all this; or,
> 2) fix it in a hurry?
>
Peter -- I've sent you an RFC patch to incorporate into your broader
patch set. I think it probably makes sense for all the Hyper-V
stuff to be a separate patch.
I haven't previously worked with the details of notrace vs. noinstr,
but I followed the patterns elsewhere in patch set. Please review
to see if it seems correct.
One thing: In the cases where I added __always_inline, I dropped
any notrace or noinstr annotations. I presume such code always
takes on the attributes of the caller. If that's not correct, let me know.
Michael
Powered by blists - more mailing lists