Re: [Xen-devel] [timer/ticks related] dom0 hang during boot on large 1TB system

[Keir Fraser <keir.fraser@xxxxxxxxxxxxx>]

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
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel