From: vda <vda@port.imtp.ilyichevsk.odessa.ua>
To: Benjamin LaHaise <bcrl@redhat.com>,
"Richard B. Johnson" <root@chaos.analogic.com>
Cc: Tim Schmielau <tim@physik3.uni-rostock.de>,
Andreas Dilger <adilger@turbolabs.com>,
linux-kernel@vger.kernel.org, J Sloan <jjs@lexus.com>
Subject: Re: [Patch] Re: Nasty suprise with uptime
Date: Fri, 2 Nov 2001 14:46:59 +0000 [thread overview]
Message-ID: <01110214465900.00784@nemo> (raw)
In-Reply-To: <20011101120222.B11773@redhat.com> <Pine.LNX.3.95.1011101125206.1496A-100000@chaos.analogic.com> <20011101133441.E11773@redhat.com>
In-Reply-To: <20011101133441.E11773@redhat.com>
On Thursday 01 November 2001 18:34, Benjamin LaHaise wrote:
> > So, if you leave jiffies alone, but bump another variable when it
> > wraps, you get to eat your cake and keep it too.
>
> As Linus pointed out, using casting tricks with a long long will just
> work for this case. Sounds good to me.
I'm using these dirty tricks often. Too often in fact, it hurts readability
and violates "make it simple if you can" principle.
Look at this diff of "simple" and "optimized" version:
-unsigned long jiffies = INITIAL_JIFFIES;
-unsigned long jiffies_hi = 0;
+/* vda: need to enforce 8 byte alignment - how??? */
+#if defined(__LITTLE_ENDIAN) && (BITS_PER_LONG == 32)
+ unsigned long jiffies = INITIAL_JIFFIES;
+ unsigned long jiffies_hi = 0;
+#elif defined(__BIG_ENDIAN) && (BITS_PER_LONG == 32)
+ unsigned long jiffies_hi = 0;
+ unsigned long jiffies = INITIAL_JIFFIES;
+#elif (BITS_PER_LONG == 64)
+ unsigned long jiffies = INITIAL_JIFFIES;
+#else
+#error Fix me somebody please....
+#endif
...
+ if(++jiffies==0) jiffies_hi++;
+#if defined(__LITTLE_ENDIAN) && (BITS_PER_LONG == 32)
+ (*(unsigned long long*)&jiffies)++;
+#elif defined(__BIG_ENDIAN) && (BITS_PER_LONG == 32)
+ (*(unsigned long long*)&jiffies_hi)++;
+#elif (BITS_PER_LONG == 64)
+ jiffies++;
+#else
+#error Fix me somebody please....
+#endif
Does saving 600 CPU cycles per second (0.000001 of your CPU power)
worth this mess?
I think not. Let's hope gcc will get smarter some day :-)
--
vda
next prev parent reply other threads:[~2001-11-02 12:54 UTC|newest]
Thread overview: 50+ messages / expand[flat|nested] mbox.gz Atom feed top
2001-10-31 22:11 [Patch] Re: Nasty suprise with uptime Petr Vandrovec
2001-10-31 21:45 ` Andreas Dilger
2001-10-31 22:58 ` Tim Schmielau
2001-10-31 23:56 ` Andreas Dilger
2001-11-01 0:23 ` Tim Schmielau
2001-11-01 0:52 ` Tim Schmielau
2001-11-01 11:21 ` george anzinger
2001-11-01 11:40 ` Tim Schmielau
2001-11-02 0:28 ` Tim Schmielau
2001-11-02 1:23 ` Andreas Dilger
2001-11-02 9:10 ` Miquel van Smoorenburg
2001-11-02 17:18 ` Tim Schmielau
2001-11-02 18:48 ` Andreas Dilger
2001-11-02 21:35 ` possibly incorrect comparisons of jiffies in linux kernel Tim Schmielau
2001-11-01 16:35 ` [Patch] Re: Nasty suprise with uptime vda
2001-11-01 15:34 ` Richard B. Johnson
2001-11-01 17:02 ` Benjamin LaHaise
2001-11-01 18:03 ` Richard B. Johnson
2001-11-01 18:34 ` Benjamin LaHaise
2001-11-02 14:46 ` vda [this message]
2001-11-01 17:29 ` george anzinger
-- strict thread matches above, loose matches on Subject: below --
2001-11-01 9:02 Petr Vandrovec
[not found] <01103121070200.01262@nemo>
2001-10-31 19:26 ` Tim Schmielau
2001-10-31 19:52 ` Richard B. Johnson
2001-10-31 20:00 ` J Sloan
2001-10-31 20:20 ` Charles Cazabon
2001-10-31 20:33 ` Kurt Roeckx
2001-10-31 20:47 ` Tim Schmielau
2001-10-31 21:07 ` Andreas Dilger
2001-10-31 21:11 ` Richard B. Johnson
2001-11-01 16:09 ` vda
2001-10-31 11:35 Tim Schmielau
2001-10-31 15:39 ` vda
2001-10-31 14:31 ` Richard B. Johnson
2001-10-31 18:16 ` Tim Schmielau
2001-10-31 18:35 ` Tim Schmielau
2001-10-31 18:59 ` Andreas Dilger
2001-10-31 18:40 ` Andreas Dilger
2001-10-31 18:58 ` Gerhard Mack
2001-10-31 19:14 ` Richard B. Johnson
2001-10-31 20:11 ` Gerhard Mack
2001-10-31 20:39 ` Richard B. Johnson
2001-10-31 20:52 ` Andreas Dilger
2001-10-31 21:05 ` Tim Schmielau
2001-10-31 21:39 ` Andreas Dilger
2001-10-31 21:17 ` Richard B. Johnson
2001-11-01 7:45 ` Ville Herva
2001-10-31 19:06 ` george anzinger
2001-10-31 22:54 ` george anzinger
2001-11-04 18:31 ` Ton Hospel
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=01110214465900.00784@nemo \
--to=vda@port.imtp.ilyichevsk.odessa.ua \
--cc=adilger@turbolabs.com \
--cc=bcrl@redhat.com \
--cc=jjs@lexus.com \
--cc=linux-kernel@vger.kernel.org \
--cc=root@chaos.analogic.com \
--cc=tim@physik3.uni-rostock.de \
/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