From: george anzinger <george@mvista.com>
To: "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
Linus Torvalds <torvalds@transmeta.com>
Subject: How should we do a 64-bit jiffies?
Date: Mon, 22 Oct 2001 08:12:24 -0700 [thread overview]
Message-ID: <3BD43758.32646D49@mvista.com> (raw)
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.
As it turns out, the only code that needs to know about the high order
bits is the code that increments jiffies and the POSIX timer code.
Every thing else can continue to use the current definition with no
problem.
The solution needs to account for the Endianess of the platform. Here
are the possible solutions I have come up with:
1.) Define jiffies in the arch section of the code using asm. Looks
like this for x86:
__asm__( ".global jiffies\n\t"
".global jiffiesll\n"
".global jiffiesh\n"
"jiffiesll:\n"
"jiffies: \n\t"
".long 0\n"
"jiffiesh: \n\t"
".long 0");
The up side of this method is that none of the current using code needs
to be aware of the change. We just remove "unsigned long volatile
jiffies;" from timer.c.
The down side of this method is that all platforms must do something
similar.
2.) Use a C structure that depends on ENDIAN defines:
#if defined(__LITTLE_ENDIAN)
union {
long long jiffiesll;
struct {
int jiffiesl
int jiffiesh
} jiffieparts;
}jiffiesu;
#elif defined(__BIG_ENDIAN)
union {
long long jiffies64;
struct {
int jiffiesh
int jiffiesl
} jiffieparts;
}jiffiesu;
#else
#error "I'm probably missing #include <asm/byteorder.h>"
#endif
#define jiffies jiffiesu.jiffieparts.jiffiesl
#define jiffiesll jiffiesu.jiffies64
The down side with this method is that jiffies can not be used as a
local or structure
element, i.e. it is now a reserved name in the kernel.
3.) Define jiffies as 64 bit and use C casts to get to the low order
part:
u64 jiffies_u64;
#define jiffies (unsigned long volatile)jiffies_u64
Here again the down side is that jiffies can not be used as a local or
structure
element, i.e. it is now a reserved name in the kernel.
I am sure there are other ways to approach this and I would like to hear
them.
Approach 1.) requires that all platforms be changed at the same time.
Approaches 2.) and 3.) require that we find all occurrences of jiffies
should not be "defined" to something else. The Ibm tick less patch
found most of these, but I am sure there are more lurking in drivers.
Comments?
George
next reply other threads:[~2001-10-22 15:13 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2001-10-22 15:12 george anzinger [this message]
2001-10-23 5:10 ` How should we do a 64-bit jiffies? 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
[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=3BD43758.32646D49@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