Re: [PATCH] Introduce jiffies_32 and related compare functions

From: Eric Dumazet
Date: Tue Dec 12 2006 - 01:57:26 EST


David Miller a écrit :
From: Eric Dumazet <dada1@xxxxxxxxxxxxx>
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 majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/