All of lore.kernel.org
 help / color / mirror / Atom feed
From: Dave Hansen <dave.hansen@intel.com>
To: Waiman Long <waiman.long@hpe.com>, Andy Lutomirski <luto@amacapital.net>
Cc: Thomas Gleixner <tglx@linutronix.de>,
	John Stultz <john.stultz@linaro.org>,
	Ingo Molnar <mingo@redhat.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Borislav Petkov <bp@suse.de>,
	Jiang Liu <jiang.liu@linux.intel.com>,
	Randy Wright <rwright@hpe.com>,
	Scott J Norton <scott.norton@hpe.com>,
	Douglas Hatch <doug.hatch@hpe.com>,
	Prarit Bhargava <prarit@redhat.com>, X86 ML <x86@kernel.org>,
	"H. Peter Anvin" <hpa@zytor.com>
Subject: Re: [RESEND PATCH v4] x86/hpet: Reduce HPET counter read contention
Date: Fri, 12 Aug 2016 14:20:15 -0700	[thread overview]
Message-ID: <57AE3D8F.9080202@intel.com> (raw)
In-Reply-To: <57AE3B61.5010202@hpe.com>

On 08/12/2016 02:10 PM, Waiman Long wrote:
>> I don't think this is right.  If the HPET ever returns the same value
>> twice in a row (unlikely because it's generally too slow to read, but
>> it's plausible that someone will make a fast HPET some day), then this
>> could deadlock.
> 
> What is the deadlock scenario you are talking about?

A reader loops waiting for the HPET update by looking for the value to
change.  If the HPET updater does an update, but the HPET itself hasn't
advanced, it will write the same value as was there before.  The reader
will keep looping thinking there was no update.

  reply	other threads:[~2016-08-12 21:20 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-08-10 18:29 [RESEND PATCH v4] x86/hpet: Reduce HPET counter read contention Waiman Long
2016-08-10 18:37 ` Long, Wai Man
2016-08-10 19:01   ` Prarit Bhargava
2016-08-11 19:32 ` Dave Hansen
2016-08-11 23:22   ` Waiman Long
2016-08-12  0:31     ` Dave Hansen
2016-08-12 17:01       ` Waiman Long
2016-08-12 17:16         ` Dave Hansen
2016-08-12 18:31           ` Waiman Long
2016-08-12 20:18             ` Andy Lutomirski
2016-08-12 21:10               ` Waiman Long
2016-08-12 21:20                 ` Dave Hansen [this message]
2016-08-12 21:32                   ` Waiman Long
2016-08-12 21:16               ` Dave Hansen
2016-08-12 21:32                 ` Waiman Long
  -- strict thread matches above, loose matches on Subject: below --
2016-06-17 20:20 Waiman Long
2016-07-13 15:02 ` Waiman Long

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=57AE3D8F.9080202@intel.com \
    --to=dave.hansen@intel.com \
    --cc=bp@suse.de \
    --cc=doug.hatch@hpe.com \
    --cc=hpa@zytor.com \
    --cc=jiang.liu@linux.intel.com \
    --cc=john.stultz@linaro.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=luto@amacapital.net \
    --cc=mingo@redhat.com \
    --cc=prarit@redhat.com \
    --cc=rwright@hpe.com \
    --cc=scott.norton@hpe.com \
    --cc=tglx@linutronix.de \
    --cc=waiman.long@hpe.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.