public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
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 07:56:35 +0100	[thread overview]
Message-ID: <457E52A3.6060503@cosmosbay.com> (raw)
In-Reply-To: <20061211.202735.104033567.davem@davemloft.net>

David Miller a écrit :
> From: Eric Dumazet <dada1@cosmosbay.com>
> 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


  reply	other threads:[~2006-12-12  6:56 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
2006-12-12  4:27             ` David Miller
2006-12-12  6:56               ` Eric Dumazet [this message]
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=457E52A3.6060503@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