David Miller a écrit :
From: Eric Dumazet <[email protected]>
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...
Eric
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
