[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <57AE4083.90601@hpe.com>
Date: Fri, 12 Aug 2016 17:32:51 -0400
From: Waiman Long <waiman.long@....com>
To: Dave Hansen <dave.hansen@...el.com>
CC: Andy Lutomirski <luto@...capital.net>,
Thomas Gleixner <tglx@...utronix.de>,
John Stultz <john.stultz@...aro.org>,
Ingo Molnar <mingo@...hat.com>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
Borislav Petkov <bp@...e.de>,
Jiang Liu <jiang.liu@...ux.intel.com>,
Randy Wright <rwright@....com>,
Scott J Norton <scott.norton@....com>,
Douglas Hatch <doug.hatch@....com>,
Prarit Bhargava <prarit@...hat.com>, X86 ML <x86@...nel.org>,
"H. Peter Anvin" <hpa@...or.com>
Subject: Re: [RESEND PATCH v4] x86/hpet: Reduce HPET counter read contention
On 08/12/2016 05:20 PM, Dave Hansen wrote:
> 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.
I should have addressed this problem in my new v5 patch.
Cheers,
Longman
Powered by blists - more mailing lists