From: Peter Zijlstra <peterz@infradead.org>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: "Stanislaw Gruszka" <sgruszka@redhat.com>,
"Linux Kernel Mailing List" <linux-kernel@vger.kernel.org>,
"Ingo Molnar" <mingo@kernel.org>,
"H. Peter Anvin" <hpa@zytor.com>,
"Frédéric Weisbecker" <fweisbec@gmail.com>,
"Steven Rostedt" <rostedt@goodmis.org>,
"Andrew Morton" <akpm@linux-foundation.org>,
"Thomas Gleixner" <tglx@linutronix.de>,
linux-tip-commits@vger.kernel.org
Subject: Re: [tip:sched/core] sched: Lower chances of cputime scaling overflow
Date: Fri, 12 Apr 2013 09:55:56 +0200 [thread overview]
Message-ID: <1365753356.17140.18.camel@laptop> (raw)
In-Reply-To: <CA+55aFway4C89fTewKvED4RvFLaNdM-BVtkJ2YChsvracLKiyA@mail.gmail.com>
On Thu, 2013-04-11 at 08:38 -0700, Linus Torvalds wrote:
> So *now*, once we are in the uncommon case, let's start counting bits.
> Like this:
>
> /* We know one of the values has a bit set in the high 32 bits */
> for (;;) {
> /* Make sure "stime" is the bigger of stime/rtime */
> if (rtime > stime) {
> u64 tmp = stime; stime = rtime; rtime = tmp;
> }
>
> /* Do we need to balance stime/rtime bits? */
> if (stime >> 32) {
> if (rtime >> 31)
> goto drop_precision;
>
> /* We can grow rtime and shrink stime and try to make them
> both fit */
> rtime <<= 1;
> stime >>= 1;
> continue;
> }
>
> /* stime/rtime fits in 32 bits, how about total? */
> if (!(total >> 32))
> break;
>
> drop_precision:
> /* We drop from stime, it has more bits than rtime */
> stime >>= 1;
> total >>= 1;
> }
>
> The above is totally untested, but each step is pretty damn simple and
> fairly cheap. Sure, it's a loop, but it's bounded to 32 (cheap)
> iterations, and the normal case is that it's not done at all, or done
> only a few times.
Right it gets gradually heavier the bigger the numbers get; which is
more and more unlikely.
> And the advantage is that the end result is always that simple
> 32x32/32 case that we started out with as the common case.
>
> I dunno. Maybe I'm overlooking something, and the above is horrible,
> but the above seems reasonably efficient if not optimal, and
> *understandable*.
I suppose that entirely matters on what one is used to ;-) I had to
stare rather hard at it for a little while.
But yes, you take it one step further and are willing to ditch rtime
bits too and I suppose that's fine.
Should work,.. Stanislaw could you stick this into your userspace
thingy and verify the numbers are sane enough?
next prev parent reply other threads:[~2013-04-12 7:56 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <tip-d9a3c9823a2e6a543eb7807fb3d15d8233817ec5@git.kernel.org>
2013-03-26 14:01 ` [tip:sched/core] sched: Lower chances of cputime scaling overflow Stanislaw Gruszka
2013-03-26 14:19 ` Frederic Weisbecker
2013-03-26 16:54 ` Stanislaw Gruszka
2013-04-10 12:51 ` Ingo Molnar
2013-04-10 15:28 ` Frederic Weisbecker
2013-04-10 17:32 ` Ingo Molnar
2013-04-11 8:04 ` Stanislaw Gruszka
2013-04-11 13:45 ` Peter Zijlstra
2013-04-11 14:50 ` Stanislaw Gruszka
2013-04-11 17:31 ` Peter Zijlstra
2013-04-11 15:38 ` Linus Torvalds
2013-04-11 18:07 ` Peter Zijlstra
2013-04-11 18:22 ` Frederic Weisbecker
2013-04-11 18:26 ` Frederic Weisbecker
2013-04-11 18:22 ` Linus Torvalds
2013-04-12 7:55 ` Peter Zijlstra [this message]
2013-04-13 14:49 ` Stanislaw Gruszka
2013-04-13 18:44 ` Linus Torvalds
2013-04-16 10:40 ` Stanislaw Gruszka
2013-04-30 14:03 ` Stanislaw Gruszka
2013-04-13 14:55 ` Stanislaw Gruszka
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=1365753356.17140.18.camel@laptop \
--to=peterz@infradead.org \
--cc=akpm@linux-foundation.org \
--cc=fweisbec@gmail.com \
--cc=hpa@zytor.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-tip-commits@vger.kernel.org \
--cc=mingo@kernel.org \
--cc=rostedt@goodmis.org \
--cc=sgruszka@redhat.com \
--cc=tglx@linutronix.de \
--cc=torvalds@linux-foundation.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;
as well as URLs for NNTP newsgroup(s).