From: Eric Dumazet <dada1@cosmosbay.com>
To: David Miller <davem@davemloft.net>
Cc: akpm@osdl.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] Introduce jiffies_32 and related compare functions
Date: Tue, 12 Dec 2006 05:09:23 +0100 [thread overview]
Message-ID: <457E2B73.9040307@cosmosbay.com> (raw)
In-Reply-To: <20061211.195737.71090466.davem@davemloft.net>
David Miller a écrit :
> From: Eric Dumazet <dada1@cosmosbay.com>
> 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 trying to make and get a discussion on.
>
>
Ah ok :)
Maybe my intentions were not clear :
I am not suggesting replacing all jiffies to jiffies_32. Just *selected* ones :)
BTW, the real limit is 2^31 ticks, so its 24 days.
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.
Eric
next prev parent reply other threads:[~2006-12-12 4:09 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <200612112027.kBBKR4nG006298@shell0.pdx.osdl.net>
2006-12-11 21:23 ` [PATCH] reorder struct pipe_buf_operations Eric Dumazet
2006-12-11 22:58 ` [PATCH] Introduce jiffies_32 and related compare functions Eric Dumazet
2006-12-12 1:31 ` David Miller
2006-12-12 3:47 ` Eric Dumazet
2006-12-12 3:57 ` David Miller
2006-12-12 4:09 ` Eric Dumazet [this message]
2006-12-12 4:27 ` David Miller
2006-12-12 6:56 ` Eric Dumazet
2006-12-12 8:00 ` David Miller
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=457E2B73.9040307@cosmosbay.com \
--to=dada1@cosmosbay.com \
--cc=akpm@osdl.org \
--cc=davem@davemloft.net \
--cc=linux-kernel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox