From: Dmitriy Zavin <dmitriyz@google.com>
To: linux-kernel@vger.kernel.org
Cc: ak@suse.de, akpm@osdl.org
Subject: [PATCH 2/4] jiffies: Add 64bit jiffies compares (for use with get_jiffies_64)
Date: Thu, 21 Sep 2006 17:48:02 -0700 [thread overview]
Message-ID: <11588860853616-git-send-email-dmitriyz@google.com> (raw)
In-Reply-To: <11588860854079-git-send-email-dmitriyz@google.com>
The current time_before/time_after macros will fail typechecks
when passed u64 values (as returned by get_jiffies_64()). On 64bit
systems, this will just result in a warning about mismatching types
without explicit casts, but since unsigned long and u64
(unsigned long long) are of same size, it will still work.
On 32bit systems, a long is 32bits, so the value from get_jiffies_64()
will be truncated by the cast and thus lose all the precision gained by
64bit jiffies.
Signed-off-by: Dmitriy Zavin <dmitriyz@google.com>
---
include/linux/jiffies.h | 15 +++++++++++++++
1 files changed, 15 insertions(+), 0 deletions(-)
diff --git a/include/linux/jiffies.h b/include/linux/jiffies.h
index 329ebcf..c8d5f20 100644
--- a/include/linux/jiffies.h
+++ b/include/linux/jiffies.h
@@ -115,6 +115,21 @@ #define time_after_eq(a,b) \
((long)(a) - (long)(b) >= 0))
#define time_before_eq(a,b) time_after_eq(b,a)
+/* Same as above, but does so with platform independent 64bit types.
+ * These must be used when utilizing jiffies_64 (i.e. return value of
+ * get_jiffies_64() */
+#define time_after64(a,b) \
+ (typecheck(__u64, a) && \
+ typecheck(__u64, b) && \
+ ((__s64)(b) - (__s64)(a) < 0))
+#define time_before64(a,b) time_after64(b,a)
+
+#define time_after_eq64(a,b) \
+ (typecheck(__u64, a) && \
+ typecheck(__u64, b) && \
+ ((__s64)(a) - (__s64)(b) >= 0))
+#define time_before_eq64(a,b) time_after_eq64(b,a)
+
/*
* Have the 32 bit jiffies value wrap 5 minutes after boot
* so jiffies wrap bugs show up earlier.
--
1.4.2
next prev parent reply other threads:[~2006-09-22 0:48 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-09-22 0:48 [PATCH 0/4 v2] therm_throt: Refactor thermal throttle processing, and keep a total count of events Dmitriy Zavin
2006-09-22 0:48 ` [PATCH 1/4] x86_64/i386 therm mce: Refactor thermal throttle processing Dmitriy Zavin
2006-09-22 0:48 ` Dmitriy Zavin [this message]
2006-09-22 0:48 ` [PATCH 3/4] therm_throt: Make the jiffies compares use the 64bit safe macros Dmitriy Zavin
2006-09-22 0:48 ` [PATCH 4/4] therm_throt: Add a cumulative thermal throttle event counter Dmitriy Zavin
2006-09-22 5:51 ` Andi Kleen
2006-09-22 5:50 ` [PATCH 1/4] x86_64/i386 therm mce: Refactor thermal throttle processing Andi Kleen
2006-09-22 5:49 ` [PATCH 0/4 v2] therm_throt: Refactor thermal throttle processing, and keep a total count of events Andi Kleen
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=11588860853616-git-send-email-dmitriyz@google.com \
--to=dmitriyz@google.com \
--cc=ak@suse.de \
--cc=akpm@osdl.org \
--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