[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CA+55aFy5Gx1OS7jaWELrpfxtwyChs=jQmoM0=HcFCjXPjgP99A@mail.gmail.com>
Date: Thu, 11 Apr 2013 11:22:27 -0700
From: Linus Torvalds <torvalds@...ux-foundation.org>
To: Peter Zijlstra <peterz@...radead.org>
Cc: Stanislaw Gruszka <sgruszka@...hat.com>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
Ingo Molnar <mingo@...nel.org>,
"H. Peter Anvin" <hpa@...or.com>,
Frédéric Weisbecker <fweisbec@...il.com>,
Steven Rostedt <rostedt@...dmis.org>,
Andrew Morton <akpm@...ux-foundation.org>,
Thomas Gleixner <tglx@...utronix.de>,
linux-tip-commits@...r.kernel.org
Subject: Re: [tip:sched/core] sched: Lower chances of cputime scaling overflow
On Thu, Apr 11, 2013 at 11:07 AM, Peter Zijlstra <peterz@...radead.org> wrote:
>
> Oh, I (wrongly it appears) assumed that fls was something cheap :/
It often is. Particularly on modern machines, because all popcount and
leading zero counting ends up being interesting to some people.
On older machines, its often a bit-at-a-time thing. We don't even try
to support i386 any more, but on atom and P4 it's something like 16
cycles for bsrl, and older cores were worse. So doing three of them
when not needed seems a bit excessive..
In contrast, on a Core2, I think it's just a single cycle.
Non-x86 architectures end up being the same - some have fast
instructions for it, others don't do it at all and end up doing things
with bitmasking and shifting.
Linus
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists