Re: How should we do a 64-bit jiffies?

From: george anzinger (george@mvista.com)
Date: Fri Oct 26 2001 - 15:59:11 EST


Linus Torvalds wrote:
>
> In article <3BD52454.218387D9@mvista.com>,
> george anzinger <george@mvista.com> wrote:
> >
> >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.
>
> ..except for gcc being bad at even 64->32-bit casts like the above. It
> will usually still load the full 64-bit value, and then only use the low
> bits.
>
> The efficient and sane way to do it is:
>
> /*
> * The 64-bit value is not volatile - you MUST NOT read it
> * without holding the spinlock
> */
Given that the spinlock would have to be spin_lock_irq (jiffies is
updated in clock interrupt code), is there a way to avoid the lock? The
following code does it for UP systems, given it is not rearranged. Is
there something like this that will work for
SMP systems?

 (assumeing the defines below):

        do {
                jiffies_f = jiffies;
                jiffies_64_f = jiffies_64;
        }
        while ( jiffies_f != jiffies);

If all things are in order, this will work on UP. Order could be
enforced by using locked instructions for the jiffies access...

George

> u64 jiffies_64;
>
> /*
> * Most people don't necessarily care about the full 64-bit
> * value, so we can just get the "unstable" low bits without
> * holding the lock. For historical reasons we also mark
> * it volatile so that busy-waiting doesn't get optimized
> * away in old drivers.
> */
> #if defined(__LITTLE_ENDIAN) || (BITS_PER_LONG > 32)
> #define jiffies (((volatile unsigned long *)&jiffies_64)[0])
> #else
> #define jiffies (((volatile unsigned long *)&jiffies_64)[1])
> #endif
>
> which looks ugly, but the ugliness is confined to that one place, and
> none of the users will ever have to care..
>
> Linus
-
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/



This archive was generated by hypermail 2b29 : Wed Oct 31 2001 - 21:00:32 EST