From: Eric Dumazet <[EMAIL PROTECTED]>
Date: Tue, 12 Dec 2006 07:56:35 +0100
> But keeping 64bits values 'just because hardware allows us this kind of
> expenditure' seems not reasonable to me, but lazy...
I agree with you for the most part.
Flexibility is pretty easy to maintain, and you seem
From: Eric Dumazet [EMAIL PROTECTED]
Date: Tue, 12 Dec 2006 07:56:35 +0100
But keeping 64bits values 'just because hardware allows us this kind of
expenditure' seems not reasonable to me, but lazy...
I agree with you for the most part.
Flexibility is pretty easy to maintain, and you seem to
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
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'
David Miller a écrit :
From: Eric Dumazet <[EMAIL PROTECTED]>
Date: Tue, 12 Dec 2006 04:47:14 +0100
I doubt being able to extend the expiration of a dst above 2^32
ticks (49 days if HZ=1000, 198 days if HZ=250) is worth the ram
wastage.
And this doesn't apply for all jiffies uses because?
From: Eric Dumazet <[EMAIL PROTECTED]>
Date: Tue, 12 Dec 2006 04:47:14 +0100
> I doubt being able to extend the expiration of a dst above 2^32
> ticks (49 days if HZ=1000, 198 days if HZ=250) is worth the ram
> wastage.
And this doesn't apply for all jiffies uses because? :-)
That's the point
David Miller a écrit :
From: Eric Dumazet <[EMAIL PROTECTED]>
Date: Mon, 11 Dec 2006 23:58:06 +0100
Some subsystems dont need more than 32bits timestamps.
See for example net/ipv4/inetpeer.c and include/net/tcp.h :
#define tcp_time_stamp((__u32)(jiffies))
Because most timeouts
From: Eric Dumazet <[EMAIL PROTECTED]>
Date: Mon, 11 Dec 2006 23:58:06 +0100
> Some subsystems dont need more than 32bits timestamps.
>
> See for example net/ipv4/inetpeer.c and include/net/tcp.h :
> #define tcp_time_stamp((__u32)(jiffies))
>
>
> Because most timeouts should work
Some subsystems dont need more than 32bits timestamps.
See for example net/ipv4/inetpeer.c and include/net/tcp.h :
#define tcp_time_stamp((__u32)(jiffies))
Because most timeouts should work with 'normal jiffies' that are 32bits on
32bits platforms, it makes sense to be able to use
Some subsystems dont need more than 32bits timestamps.
See for example net/ipv4/inetpeer.c and include/net/tcp.h :
#define tcp_time_stamp((__u32)(jiffies))
Because most timeouts should work with 'normal jiffies' that are 32bits on
32bits platforms, it makes sense to be able to use
From: Eric Dumazet [EMAIL PROTECTED]
Date: Mon, 11 Dec 2006 23:58:06 +0100
Some subsystems dont need more than 32bits timestamps.
See for example net/ipv4/inetpeer.c and include/net/tcp.h :
#define tcp_time_stamp((__u32)(jiffies))
Because most timeouts should work with
David Miller a écrit :
From: Eric Dumazet [EMAIL PROTECTED]
Date: Mon, 11 Dec 2006 23:58:06 +0100
Some subsystems dont need more than 32bits timestamps.
See for example net/ipv4/inetpeer.c and include/net/tcp.h :
#define tcp_time_stamp((__u32)(jiffies))
Because most timeouts
From: Eric Dumazet [EMAIL PROTECTED]
Date: Tue, 12 Dec 2006 04:47:14 +0100
I doubt being able to extend the expiration of a dst above 2^32
ticks (49 days if HZ=1000, 198 days if HZ=250) is worth the ram
wastage.
And this doesn't apply for all jiffies uses because? :-)
That's the point I'm
David Miller a écrit :
From: Eric Dumazet [EMAIL PROTECTED]
Date: Tue, 12 Dec 2006 04:47:14 +0100
I doubt being able to extend the expiration of a dst above 2^32
ticks (49 days if HZ=1000, 198 days if HZ=250) is worth the ram
wastage.
And this doesn't apply for all jiffies uses because? :-)
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
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
16 matches
Mail list logo
