lkml.org 
[lkml]   [2001]   [Oct]   [23]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: How should we do a 64-bit jiffies?
Keith Owens wrote:
>
> On Mon, 22 Oct 2001 08:12:24 -0700,
> george anzinger <george@mvista.com> wrote:
> >I am working on POSIX timers where there is defined a CLOCK_MONOTONIC.
> >The most reasonable implementation of this clock is that it is "uptime"
> >or jiffies. The problem is that it is most definitely not MONOTONIC
> >when it rolls back to 0 :( Thus the need for 64-bits.
>
> If you want to leave existing kernel code alone so it still uses 32 bit
> jiffies, just maintain a separate high order 32 bit field which is only
> used by the code that really needs it. On 32 bit machines, the jiffie
> code does
>
> old_jiffies = jiffies++;
> if (jiffies < old_jiffies)
> ++high_jiffies;
>
> You will need a spin lock around that on 32 bit systems, but that is
> true for anything that tries to do 64 bit counter updates on a 32 bit
> system. None of your suggestions will work on ix86, it does not
> support atomic updates on 64 bit fields in hardware.

As it turns out I already have a spinlock on the update jiffies code.
The reason one would want to use a 64-bit integer is that the compiler
does a MUCH better job of the ++, i.e. it just does an add carry. No
if, no jmp. I suppose I need to lock the read also, but it is not done
often and will hardly ever block.

I am beginning to think that defining a u64 and casting, i.e.:

#define jiffies (unsigned long volitial)jiffies_u64

is the way to go.

George
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 13:10    [W:3.138 / U:0.544 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site