From: george anzinger <george@mvista.com>
To: Linus Torvalds <torvalds@transmeta.com>
Cc: linux-kernel@vger.kernel.org
Subject: Re: How should we do a 64-bit jiffies?
Date: Fri, 26 Oct 2001 13:59:11 -0700 [thread overview]
Message-ID: <3BD9CE9F.16B2E2B5@mvista.com> (raw)
In-Reply-To: <1164.1003813848@ocs3.intra.ocs.com.au> <3BD52454.218387D9@mvista.com> <9r43b6$1as$1@penguin.transmeta.com>
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
next prev parent reply other threads:[~2001-10-26 20:59 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2001-10-22 15:12 How should we do a 64-bit jiffies? george anzinger
2001-10-23 5:10 ` Keith Owens
2001-10-23 6:05 ` Brian Gerst
2001-10-23 6:23 ` Keith Owens
2001-10-23 8:03 ` george anzinger
2001-10-23 15:45 ` Linus Torvalds
2001-10-26 20:59 ` george anzinger [this message]
[not found] ` <200110231545.f9NFjgg01377@penguin.transmeta.com>
2002-05-10 21:35 ` 64-bit jiffies, a better solution george anzinger
2002-05-10 21:52 ` Linus Torvalds
2002-05-10 22:36 ` george anzinger
2002-05-10 22:40 ` Linus Torvalds
2002-05-11 0:42 ` 64-bit jiffies, a better solution take 2 george anzinger
2002-05-11 8:29 ` Russell King
2002-05-11 15:01 ` george anzinger
2002-05-11 16:10 ` Russell King
2002-05-11 17:31 ` george anzinger
2002-05-11 17:37 ` Linus Torvalds
2002-05-11 18:11 ` Russell King
2002-05-11 23:38 ` Keith Owens
2002-05-12 0:01 ` Russell King
2002-05-12 0:31 ` Keith Owens
2002-05-12 8:12 ` george anzinger
[not found] ` <3CDD6DA1.7B259EF1@mvista.com>
[not found] ` <20020511201748.G1574@flint.arm.linux.org.uk>
2002-05-12 8:03 ` 64-bit jiffies, a better solution take 2 (Fix ARM) george anzinger
2002-05-11 16:41 ` 64-bit jiffies, a better solution take 2 Daniel Jacobowitz
2002-05-13 11:09 ` 64-bit jiffies, a better solution Maciej W. Rozycki
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=3BD9CE9F.16B2E2B5@mvista.com \
--to=george@mvista.com \
--cc=linux-kernel@vger.kernel.org \
--cc=torvalds@transmeta.com \
/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