[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20200226213111.GB113541@romley-ivt3.sc.intel.com>
Date: Wed, 26 Feb 2020 13:31:11 -0800
From: Fenghua Yu <fenghua.yu@...el.com>
To: Andi Kleen <ak@...ux.intel.com>
Cc: Kyung Min Park <kyung.min.park@...el.com>, x86@...nel.org,
linux-kernel@...r.kernel.org, tglx@...utronix.de, mingo@...hat.com,
hpa@...or.com, gregkh@...uxfoundation.org, tony.luck@...el.com,
ashok.raj@...el.com, ravi.v.shankar@...el.com
Subject: Re: [PATCH 2/2] x86/asm/delay: Introduce TPAUSE delay
On Wed, Feb 26, 2020 at 01:10:40PM -0800, Andi Kleen wrote:
> On Wed, Feb 26, 2020 at 11:10:58AM -0800, Kyung Min Park wrote:
> > TPAUSE instructs the processor to enter an implementation-dependent
> > optimized state. The instruction execution wakes up when the time-stamp
> > counter reaches or exceeds the implicit EDX:EAX 64-bit input value.
> > The instruction execution also wakes up due to the expiration of
> > the operating system time-limit or by an external interrupt
>
> This is actually a behavior change. Today's udelay() will continue
> after processing the interrupt. Your patches don't
>
> I don't think it's a problem though. The interrupt will cause
> a long enough delay that exceed any reasonable udelay() requirements.
>
> There would be a difference if someone did really long udelay()s, much
> longer than typical interrupts, in this case you might end up
> with a truncated udelay, but such long udelays are not something that we
> would encourage.
TPAUSE is in a loop which checks if this udelay exceeds deadline.
Coming back from interrupt, the loop checks deadline and finds
there is still left time to delay. Then udelay() goes back to TPAUSE.
Thanks.
-Fenghua
Powered by blists - more mailing lists