From mboxrd@z Thu Jan  1 00:00:00 1970
From: Andrew Cooper <andrew.cooper3@citrix.com>
Subject: Re: [PATCH v5 2/5] x86/hpet: Use singe apic vector
 rather than irq_descs for HPET interrupts
Date: Thu, 6 Mar 2014 14:40:51 +0000
Message-ID: <531888F3.8000504@citrix.com>
References: <1394034226-14327-1-git-send-email-andrew.cooper3@citrix.com>
	<1394034226-14327-3-git-send-email-andrew.cooper3@citrix.com>
	<5318956402000078001218FA@nat28.tlf.novell.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Return-path: <xen-devel-bounces@lists.xen.org>
In-Reply-To: <5318956402000078001218FA@nat28.tlf.novell.com>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org
To: Jan Beulich <JBeulich@suse.com>
Cc: Tim Deegan <tim@xen.org>, Frediano Ziglio <frediano.ziglio@citrix.com>, Keir Fraser <keir@xen.org>, Xen-devel <xen-devel@lists.xen.org>
List-Id: xen-devel@lists.xenproject.org

On 06/03/14 14:33, Jan Beulich wrote:
>>>> On 05.03.14 at 16:43, Andrew Cooper <andrew.cooper3@citrix.com> wrote:
>>  ** If an HPET firing at an appropriate time can be found (up to 20us late), a
>>     CPU will simply request to be woken up with that HPET.
> With exit latencies from C1/C1E in the range of 1...10us, 20us seems
> like a lot of additional latency added here.

Well - it is down from 50us, and also not ahead of time.  Any narrowing
of this window does mean higher contention when fighting over the
remaining hpets.

>
>>  ** Failing finding an appropriate timed HPET, a CPU shall find the soonest
>>     late HPET and program it earlier.
>>  ** Failing any late HPETs, a CPU shall wake up with the latest early HPET it
>>     can find.
> And do what?

Wake up early, in the hope that the hpet arrangements are different when
it next comes to look

>
>>  ** Failing all else, a CPU shall retry to find a free HPET.  This guarantees
>>     that a CPU will never leave hpet_broadcast_enter() without arranging an
>>     interrupt.
> For how long? Indefinitely (i.e. until the wakeup time is reached)?
>
> All without having looked at the details of the patch yet.
>
> Jan
>

Forever.  There are certain sleep paths which cannot be aborted by this
point, so exiting without having set up a wakup is not an option.

A different option would be to make all sleep paths abortable, at which
point my v4 series would be appropriate (plus spinlock bugfix)

~Andrew