[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CA+55aFw70ZvHKH+8_aS7E7FZZuuWQA++zGQuSmuvDE3DWU+x3A@mail.gmail.com>
Date: Wed, 7 Jan 2015 11:36:33 -0800
From: Linus Torvalds <torvalds@...ux-foundation.org>
To: Nicolas Pitre <nicolas.pitre@...aro.org>
Cc: Catalin Marinas <catalin.marinas@....com>,
Russell King - ARM Linux <linux@....linux.org.uk>,
Pavel Machek <pavel@....cz>,
Marc Zyngier <marc.zyngier@....com>,
kernel list <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] Revert 9fc2105aeaaf56b0cf75296a84702d0f9e64437b to fix
pyaudio (and probably more)
On Wed, Jan 7, 2015 at 11:00 AM, Nicolas Pitre <nicolas.pitre@...aro.org> wrote:
>
> We'll make sure it is scaled properly so not to have orders of magnitude
> discrepancy whether the timer based or the CPU based loop is used for
> the purpose of making people feel good.
Why?
You'd basically be lying. And it might actually hide real problems.
If the scaling hides the fact that the timer source cannot do a good
job at microsecond resolution delays, then it's not just lying, it's
lying in ways that hide real issues. So why should that kind of
behavior be encouraged? The actual *real* unscaled resolution of the
timer is valid and real information.
Random scaling like that would be *bad*, in other words.
This whole thread has wasted more time than the whole original
argument for wasted time ever was. I still have no idea what the
original argument was, and why you guys want some made-up and
incorrect feel-good number rather than just document the fact that the
bogomips is simple dependent on the clocksource you use for delays.
That kind of documentation wouldn't be lying, wouldn't be misleading,
and wouldn't waste peoples time.
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