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-devel] [timer/ticks related] dom0 hang during boot on large 1TB

To: Mukesh Rathor <mukesh.rathor@xxxxxxxxxx>, Steve Ofsthun <steve.ofsthun@xxxxxxxxxx>
Subject: Re: [Xen-devel] [timer/ticks related] dom0 hang during boot on large 1TB system
From: Keir Fraser <keir.fraser@xxxxxxxxxxxxx>
Date: Tue, 22 Dec 2009 07:59:22 +0000
Cc: Hackel <kurt.hackel@xxxxxxxxxx>, Dan Magenheimer <dan.magenheimer@xxxxxxxxxx>, "Xen-devel@xxxxxxxxxxxxxxxxxxx" <Xen-devel@xxxxxxxxxxxxxxxxxxx>, Jeremy Fitzhardinge <jeremy@xxxxxxxx>, "Kurt@xxxxxxxxxxxxxxxxxxxx" <Kurt@xxxxxxxxxxxxxxxxxxxx>
Delivery-date: Mon, 21 Dec 2009 23:59:54 -0800
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <20091221200025.3641d635@xxxxxxxxxxxxxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: AcqCu5B+1vvCLLjaSZKdo68/Z6EcsQAIRtJS
Thread-topic: [Xen-devel] [timer/ticks related] dom0 hang during boot on large 1TB system
User-agent: Microsoft-Entourage/
I'll try and make this *really* clear...

On 22/12/2009 04:00, "Mukesh Rathor" <mukesh.rathor@xxxxxxxxxx> wrote:

> can't use time_after/before as they do signed comparisions.
>   time_after(a,b): ((long)(b) - (long)(a) < 0))

The whole point is to do signed comparison. This gives you reliable +/-
(BITS_PER_LONG-1) bits to reliably compare: with 32-bit Linux that means
jiffy values which do not differ by more than +/- 2^31 can be reliably
compared, regardless of wrapping. Bear in mind that even at HZ=1000, it'll
take 3.5 *weeks* for jiffies to increase by 2^31.
> thus, time_after(0xFFFEDB09, 0xFFFEDB08) will return true as will
> time_after(0x1020, 0xFFFEDB08) as they are both after 0xFFFEDB08.

Well yeah: anything in the ranges a=0xFFFEDB09-0xFFFFFFFF and
a=0x0-0x7FFEDB09 will return true for time_after(a,0xFFFEDB08). That's how a
signed 32-bit comparison works. The assumption here is that 0x1020 is
derived from jiffies_64=0x100001020: in general the assumption is that the
arguments to time_after() were taken within seconds/minutes/hours of each
other, not days/weeks. Which precludes a jiffies_64 difference of
>0x7FFFFFFF, which is what would invalidate use of time_after().

> For wrapping, unsigned comparision must be done, which is also the jiffies
> data type. 

If you do 32-bit unsigned comparisons, that is broken by jiffies wrapping,
the fixing of which was the whole point of the comparison macros.

 -- Keir

Xen-devel mailing list