This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
Home Products Support Community News


Re: [Xen-ia64-devel] Question about time_interpolator_get_counter() in R

To: Masaki Kanno <kanno.masaki@xxxxxxxxxxxxxx>
Subject: Re: [Xen-ia64-devel] Question about time_interpolator_get_counter() in RHEL4
From: Alex Williamson <alex.williamson@xxxxxx>
Date: Mon, 15 Jan 2007 08:26:39 -0700
Cc: xen-ia64-devel@xxxxxxxxxxxxxxxxxxx
Delivery-date: Mon, 15 Jan 2007 07:26:15 -0800
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <8C7388C53FDB9kanno.masaki@xxxxxxxxxxxxxx>
List-help: <mailto:xen-ia64-devel-request@lists.xensource.com?subject=help>
List-id: Discussion of the ia64 port of Xen <xen-ia64-devel.lists.xensource.com>
List-post: <mailto:xen-ia64-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-ia64-devel>, <mailto:xen-ia64-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-ia64-devel>, <mailto:xen-ia64-devel-request@lists.xensource.com?subject=unsubscribe>
Organization: HP OSLO R&D
References: <8C7388C53FDB9kanno.masaki@xxxxxxxxxxxxxx>
Sender: xen-ia64-devel-bounces@xxxxxxxxxxxxxxxxxxx
On Mon, 2007-01-15 at 19:02 +0900, Masaki Kanno wrote:
> Hi Alex,
> Could you comment a this issue? 
> When we tested RHEL4 on domVTi of SMP, we met with hanging up of the 
> RHEL4. We examined this issue with the xenctx. As a result, the each 
> VCPUs of domVTi seemed to be looping in the following functions. 
>  - A VCPU is looping in time_interpolator_get_counter(). 
>  - Other VCPUs are looping in fsys_gettimeofday(). 
> When we were examining this issue further, we found your patch about 
> time_interpolator_get_counter(). 
>   [PATCH] optimize writer path in time_interpolator_get_counter()
>   http://lkml.org/lkml/2005/8/1/134

Hi Kan,

   That sounds like the right scenario.  Both of these code paths are
using seqlocks to allow multiple CPUs to try to update the last_cycle
value via a cmpxchg.  The optimization I added allows the CPU holding
the write lock to update the last_cycle counter and exit without
competing with the other CPUs in the cmpxchg.  This significantly
reduces the contention caused by the cmpxchg and maintains correctness
because the readers (on the fsys_gettimeofday path) cannot exit while a
write seqlock is held.  I only saw a true live-lock in this code segment
with a prototype processor, but the possibility for it certainly exists.
I could see the scheduling of vCPUs potentially making this problem more
likely.  Thanks,


Alex Williamson                             HP Open Source & Linux Org.

Xen-ia64-devel mailing list

<Prev in Thread] Current Thread [Next in Thread>