Re: [PATCH] Revert 9fc2105aeaaf56b0cf75296a84702d0f9e64437b to fix pyaudio (and probably more)

[Catalin Marinas]

On 6 January 2015 at 22:33, Linus Torvalds
<torvalds@xxxxxxxxxxxxxxxxxxxx> wrote:
> On Mon, Jan 5, 2015 at 10:22 AM, Catalin Marinas
> <catalin.marinas@xxxxxxx> wrote:
>>
>> If the always constant bogomips is not desirable, we are left with
>> having to do a dummy calibration to guess some value to be reported to
>> user as BogoMIPS.
>
> Not at all.
>
> Just use whatever counter frequency you use for the delay loop (and
> traditionally, you multiply by two, since the *original* bogomips loop
> was two instructions).
>
> That's why the bogomips printout has that "500000" value. It's
> multiplying by two, and then dividing by a million to get MHz.
>
> That's what bogomips *is*, for chrissake! It's a bogus measure of how
> many times you go through the delay loop.

I think that's where the misunderstanding is. We don't have any idea
how many times we go through the delay loop. We just go through the
delay loop until the counter (driven by an independent frequency)
changes X times. From arch/arm/lib/delay.c:

static void __timer_delay(unsigned long cycles)
{
        cycles_t start = get_cycles();

        while ((get_cycles() - start) < cycles)
                cpu_relax();
}

where the number of cycles is based on the pre-calculated lpj_fine
value using the counter/timer frequency (read from DT or hardware).

I think Nico already pointed out that the way we use loops_per_jiffy
when the udelay is timer-based is probably wrong. We actually need a
ticks_per_jiffy which has nothing to do with loops_per_jiffy, the
former is actually completely independent from the CPU speed.

> And the delay loop does *not* have to be that "decrement and loop". It
> can be "read timer and loop". Since the delay loop is all about
> microseconds, your timer had betterr have a frequency in the MHz range
> anyway.

That's true.

> On some platforms, it could be the traditional sw-based loop counter
> because it's the only thing you have. On others, it could be a CPU
> cycle counter. On yet others, it could be a specialized timer counter.
> It doesn't matter, all is valid.
>
> What is *not* valid is clearly:
>
>  - removing the bogomips line.

I think we all agree here (now).

>    You can try again in a couple of years. Maybe nobody will notice.
> But people *did* notice, and that commit got reverted. End of story,
> anybody who argues for removal is simply wrong.
>
>  - making shit up

Well, reporting timer ticks per jiffy no matter what CPU frequency
doesn't look very far from "making shit up" to me.

>    Bogomips is a bogus benchmark, but it is *not* a constant number,
> and it *does* have to do with the timing loop.
>
> The "making shit up" case is less wrong (pretty much by definition,
> since "breaking user space applications" is the most wrong you can
> ever be), but you know what? bogomips has a long history of bogosity.
> It's integral. It goes back a long time. It has historical
> significance. It isn't 0.01 material, but it was certainly added
> before 1.0.
>
> .. and it's still a better benchmark than dhrystone.

With the current arm timer-based (and arm64) implementation, the
reported BogoMIPS has nothing to do with the CPU benchmark. It just
tells you that a X MHz counter needs X*1000000/HZ ticks per jiffy.

(that's another reason we removed it; to stop marketing people from
complaining that Linux doesn't look fast on newer ARM CPUs)

So reverting the patch is just the first step, we need to make up some
more real loops_per_jiffy now. It's not hard, something like counting
how many get_cycle() loops we can get for a jiffy and multiplying it
with the number of instructions in the loop.

-- 
Catalin
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/