All of lore.kernel.org
 help / color / mirror / Atom feed
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


  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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.