From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S1752590AbcHLVUR (ORCPT <rfc822;w@1wt.eu>);
	Fri, 12 Aug 2016 17:20:17 -0400
Received: from mga09.intel.com ([134.134.136.24]:48829 "EHLO mga09.intel.com"
	rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP
	id S1751010AbcHLVUQ (ORCPT <rfc822;linux-kernel@vger.kernel.org>);
	Fri, 12 Aug 2016 17:20:16 -0400
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.28,512,1464678000"; 
   d="scan'208";a="1034687053"
Subject: Re: [RESEND PATCH v4] x86/hpet: Reduce HPET counter read contention
To: Waiman Long <waiman.long@hpe.com>, Andy Lutomirski <luto@amacapital.net>
References: <1470853770-37625-1-git-send-email-Waiman.Long@hpe.com>
 <57ACD2DE.6080306@intel.com> <57AD0898.7030506@hpe.com>
 <57AD18D1.1050107@intel.com> <57AE00EE.8070904@hpe.com>
 <57AE0469.10503@intel.com> <57AE1606.2010304@hpe.com>
 <CALCETrWaVFPkP=aP+KW_sQQ+6M0gOtVbgg2awJqck93PFJHJsw@mail.gmail.com>
 <57AE3B61.5010202@hpe.com>
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>
From: Dave Hansen <dave.hansen@intel.com>
Message-ID: <57AE3D8F.9080202@intel.com>
Date: Fri, 12 Aug 2016 14:20:15 -0700
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101
 Thunderbird/38.8.0
MIME-Version: 1.0
In-Reply-To: <57AE3B61.5010202@hpe.com>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

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.