On Wed, Jan 7, 2015 at 10:11 AM, Catalin Marinas
<catalin.mari...@arm.com> wrote:
>
> I think this makes sense since __delay() expects the number of loops
> as argument rather than a duration scaled by some factor (based on the
> generic timer frequency).
Gaah. You guys make no sense at all.
No, __delay() does not expect "number of loops".
It doesn't do that on x86, and it doesn't even do it on arm.
It *literally* does exactly the reverse of what you say it does.
__delay() very much expects a "duration scaled by some factor". The
factor being "loops_per_jiffy" (ok, so it's a "reverse factor", but
you get the idea).
And this is very much exactly why bogomips is that "2 *
loops_per_jiffy * HZ / 1000000".
Let's break it down:
- "loops_per_jiffy" is just the scale factor for __udelay(). Ignore
the "loops" part of the name, since it's purely historical. It comes
from the original "decrement and jump" implementation, but that hasn't
been true on x86 for over 15 years.
- the "2x" factor is also purely historical, and comes from the same
"decrement and jump" thing - it used to be two instructions. But
again, it hasn't been true for a *looong* time, but it is part of the
bogosity of bogomips.
- the "*HZ" is the "per jiffy" part.
- the "1000000" is the "MHz" part. The clock had better tick at a
megahertz or more, since the whole point of this is to do "udelay()".
Really. The original commit that removed bogomips from ARM was
*wrong*. Because that
per_cpu(cpu_data, i).loops_per_jiffy / (500000UL/HZ
calculation is in fact the very DEFINITION of bogomips (it's just
written in a way to not overflow).
Seriously.
The reason I reverted that commit is because it was crap. When Pavel
made the report, I looked at the code, and immediately reverted it.
For good reason. Exactly because that original patch was WRONG.
The old bogomips computation in arch/arm/kernel/setup.c is exactly the
right thing to do.
And every time somebody thinks it has to be about "loops" or about
"cpu frequency", I can only say "STOP IT". It hasn't been about loops
or CPU frequency for ages. I don't know when we switched it to "wait
for the timer", because it predates my history that starts in early
2002. So it's at *least* 13 years old.
Linus
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
