All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andi Kleen <ak@linux.intel.com>
To: Kyung Min Park <kyung.min.park@intel.com>
Cc: x86@kernel.org, linux-kernel@vger.kernel.org, tglx@linutronix.de,
	mingo@redhat.com, hpa@zytor.com, gregkh@linuxfoundation.org,
	tony.luck@intel.com, ashok.raj@intel.com,
	ravi.v.shankar@intel.com, fenghua.yu@intel.com
Subject: Re: [PATCH 2/2] x86/asm/delay: Introduce TPAUSE delay
Date: Wed, 26 Feb 2020 13:10:40 -0800	[thread overview]
Message-ID: <20200226211040.GS160988@tassilo.jf.intel.com> (raw)
In-Reply-To: <1582744258-42744-3-git-send-email-kyung.min.park@intel.com>

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.

I don't think you need to change anything in the code, but should
probably document this behavior.

-Andi

  reply	other threads:[~2020-02-26 21:10 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-02-26 19:10 [PATCH 0/2] x86/delay: Introduce TPAUSE instruction Kyung Min Park
2020-02-26 19:10 ` [PATCH 1/2] x86/asm: Define a few helpers in delay_waitx() Kyung Min Park
2020-03-18 20:19   ` Thomas Gleixner
2020-02-26 19:10 ` [PATCH 2/2] x86/asm/delay: Introduce TPAUSE delay Kyung Min Park
2020-02-26 21:10   ` Andi Kleen [this message]
2020-02-26 21:20     ` Luck, Tony
2020-02-26 21:59       ` Andi Kleen
2020-02-26 21:31     ` Fenghua Yu

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=20200226211040.GS160988@tassilo.jf.intel.com \
    --to=ak@linux.intel.com \
    --cc=ashok.raj@intel.com \
    --cc=fenghua.yu@intel.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=hpa@zytor.com \
    --cc=kyung.min.park@intel.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@redhat.com \
    --cc=ravi.v.shankar@intel.com \
    --cc=tglx@linutronix.de \
    --cc=tony.luck@intel.com \
    --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.