[lkml]   [2006]   [Dec]   [12]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [PATCH] Introduce jiffies_32 and related compare functions
David Miller a écrit :
> From: Eric Dumazet <>
> Date: Tue, 12 Dec 2006 05:09:23 +0100
>> We definitly *like* being able to use bigger timeouts on 64bits platforms.
>> Not that they are mandatory since the same application should run fine on
>> 32bits kernel. But as the standard type for 'tick timestamps' is 'unsigned
>> long', a change would be invasive.
>> Maybe some applications are now relying on being able to
>> sleep()/select()/poll() for periods > 30 days and only run on 64
>> bits kernels.
> I think one possible target would be struct timer, at least
> in theory.
> There is also a line of reasoning that says that on 64-bit
> platforms we have some flexibility to set HZ very large, if
> we wanted to at some point, and going to 32-bit jiffies
> storage for some things may eliminate that kind of flexibility.

Yes good point, and my understanding is that we go for a tickless kernel in
2.6.21, or so.
I wonder if virtual HZ wont be sticked to a low value.

I suspect in the case HZ raises, we switch some/most uses of jiffies_32 to
another variable (xtime_32 or whatever), but keep the storage on 32bits...

But keeping 64bits values 'just because hardware allows us this kind of
expenditure' seems not reasonable to me, but lazy...


To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2006-12-12 07:59    [W:0.032 / U:5.836 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site