Hi all,
This small patch set may look a little over a month late, but there is a
serious reason for posting it.
When I moved the ARM delay loop over to using the architected timers
rather than the CPU spinning loop (which has all the problems associated
with cpu frequency scaling and what-not) I thought I was doing something
useful for the port. However, it turns out that a surprising number of
people have complained, and continue to complain, about the drop in
their `BogoMIPs score'.
After some education, they usually give in, but I figured it could be
solved by removing the reporting of this number to userspace altogether.
Unfortunately, that affects the output of /proc/cpuinfo, which I'm not
comfortable changing, so instead I've written this slightly tongue-in-cheek
series reporting obviously bogus values in those fields in the hope that
people don't interpret them as anything meaningful.
Comments welcome,
Will
Will Deacon (2):
ARM: delay: print dummy values for bogomips
init: calibrate: don't print out bogomips value on boot
arch/arm/Kconfig.debug | 48 ++++++++++++++++++++++++++++++++++++++++++++++++
arch/arm/kernel/setup.c | 16 ++++++++--------
arch/arm/kernel/smp.c | 13 ++-----------
init/calibrate.c | 8 +++-----
4 files changed, 61 insertions(+), 24 deletions(-)
--
1.8.2.2
Now that we support a timer-backed delay loop, I'm quickly getting sick
and tired of people complaining that their beloved bogomips value has
decreased. You know who you are!
Unfortunately, we can't just remove the entry from /proc/cpuinfo, as it
will likely break fragile userspace code which is parsing that stuff, so
instead replace it with a dummy value that can be chosen in the Kconfig.
Signed-off-by: Will Deacon <[email protected]>
---
arch/arm/Kconfig.debug | 48 ++++++++++++++++++++++++++++++++++++++++++++++++
arch/arm/kernel/setup.c | 16 ++++++++--------
arch/arm/kernel/smp.c | 13 ++-----------
3 files changed, 58 insertions(+), 19 deletions(-)
diff --git a/arch/arm/Kconfig.debug b/arch/arm/Kconfig.debug
index 9b31f43..5a0fce1 100644
--- a/arch/arm/Kconfig.debug
+++ b/arch/arm/Kconfig.debug
@@ -633,4 +633,52 @@ config PID_IN_CONTEXTIDR
additional instructions during context switch. Say Y here only if you
are planning to use hardware trace tools with this kernel.
+choice
+ prompt "BogoMIPs setting"
+ default BOGOMIPS_MEDIUM
+ help
+ The BogoMIPs value reported by Linux is exactly what it sounds
+ like: totally bogus. It is used to calibrate the delay loop,
+ which may be backed by a timer clocked completely independently
+ of the CPU.
+
+ Unfortunately, that doesn't stop marketing types (and even people
+ who should know better) from using the number to compare machines
+ and then screaming if it's less than some fictitious, expected
+ value.
+
+ So, this option can be used to avoid the inevitable amount of
+ pain and suffering you will endure when the chaps described above
+ start parsing /proc/cpuinfo.
+
+ config BOGOMIPS_SLOW
+ bool "Slow (older machines)"
+ help
+ If you're comparing a faster machine with a slower machine,
+ then you might want this option selected on one of them.
+
+ config BOGOMIPS_MEDIUM
+ bool "Medium (default)"
+ help
+ A BogoMIPS value for the masses.
+
+ config BOGOMIPS_FAST
+ bool "Fast (marketing)"
+ help
+ Some people believe that software runs faster with this
+ setting so, if you're one of them, say Y here.
+
+ config BOGOMIPS_RANDOM
+ bool "Random (increased Bogosity)"
+ help
+ Putting the Bogo back into BogoMIPs.
+endchoice
+
+config BOGOMIPS
+ int
+ default 1 if BOGOMIPS_SLOW
+ default 10000 if BOGOMIPS_MEDIUM
+ default 99999 if BOGOMIPS_FAST
+ default 0
+
endmenu
diff --git a/arch/arm/kernel/setup.c b/arch/arm/kernel/setup.c
index ec04c16..7996a12 100644
--- a/arch/arm/kernel/setup.c
+++ b/arch/arm/kernel/setup.c
@@ -30,6 +30,7 @@
#include <linux/compiler.h>
#include <linux/sort.h>
#include <linux/debugfs.h>
+#include <linux/random.h>
#include <asm/unified.h>
#include <asm/cp15.h>
@@ -878,7 +879,7 @@ static const char *hwcap_str[] = {
static int c_show(struct seq_file *m, void *v)
{
int i, j;
- u32 cpuid;
+ u32 cpuid, bogomips;
for_each_online_cpu(i) {
/*
@@ -891,15 +892,14 @@ static int c_show(struct seq_file *m, void *v)
seq_printf(m, "model name\t: %s rev %d (%s)\n",
cpu_name, cpuid & 15, elf_platform);
-#if defined(CONFIG_SMP)
- seq_printf(m, "BogoMIPS\t: %lu.%02lu\n",
- per_cpu(cpu_data, i).loops_per_jiffy / (500000UL/HZ),
- (per_cpu(cpu_data, i).loops_per_jiffy / (5000UL/HZ)) % 100);
+#ifdef CONFIG_BOGOMIPS_RANDOM
+ get_random_bytes(&bogomips, sizeof(bogomips));
+ bogomips &= USHRT_MAX;
#else
- seq_printf(m, "BogoMIPS\t: %lu.%02lu\n",
- loops_per_jiffy / (500000/HZ),
- (loops_per_jiffy / (5000/HZ)) % 100);
+ bogomips = CONFIG_BOGOMIPS;
#endif
+ seq_printf(m, "BogoMIPS\t: %u.00\n", bogomips);
+
/* dump out the processor features */
seq_puts(m, "Features\t: ");
diff --git a/arch/arm/kernel/smp.c b/arch/arm/kernel/smp.c
index 1f2cccc..8acff93 100644
--- a/arch/arm/kernel/smp.c
+++ b/arch/arm/kernel/smp.c
@@ -341,17 +341,8 @@ asmlinkage void __cpuinit secondary_start_kernel(void)
void __init smp_cpus_done(unsigned int max_cpus)
{
- int cpu;
- unsigned long bogosum = 0;
-
- for_each_online_cpu(cpu)
- bogosum += per_cpu(cpu_data, cpu).loops_per_jiffy;
-
- printk(KERN_INFO "SMP: Total of %d processors activated "
- "(%lu.%02lu BogoMIPS).\n",
- num_online_cpus(),
- bogosum / (500000/HZ),
- (bogosum / (5000/HZ)) % 100);
+ printk(KERN_INFO "SMP: Total of %d processors activated.\n",
+ num_online_cpus());
hyp_mode_check();
}
--
1.8.2.2
BogoMIPs is a confusing concept, so allow architectures to print it only
if they find it worthwhile. The delay calibration code should stick to
lpj and avoid trying to draw any correlation with BogoMIPs, which may be
a fixed, bogus (geddit?) value.
Signed-off-by: Will Deacon <[email protected]>
---
init/calibrate.c | 8 +++-----
1 file changed, 3 insertions(+), 5 deletions(-)
diff --git a/init/calibrate.c b/init/calibrate.c
index fda0a7b..cf48068 100644
--- a/init/calibrate.c
+++ b/init/calibrate.c
@@ -135,13 +135,13 @@ static unsigned long __cpuinit calibrate_delay_direct(void)
if ((measured_times[max] - estimate) <
(estimate - measured_times[min])) {
printk(KERN_NOTICE "calibrate_delay_direct() dropping "
- "min bogoMips estimate %d = %lu\n",
+ "min delay estimate %d = %lu\n",
min, measured_times[min]);
measured_times[min] = 0;
min = max;
} else {
printk(KERN_NOTICE "calibrate_delay_direct() dropping "
- "max bogoMips estimate %d = %lu\n",
+ "max delay estimate %d = %lu\n",
max, measured_times[max]);
measured_times[max] = 0;
max = min;
@@ -292,9 +292,7 @@ void __cpuinit calibrate_delay(void)
}
per_cpu(cpu_loops_per_jiffy, this_cpu) = lpj;
if (!printed)
- pr_cont("%lu.%02lu BogoMIPS (lpj=%lu)\n",
- lpj/(500000/HZ),
- (lpj/(5000/HZ)) % 100, lpj);
+ pr_cont("lpj=%lu\n", lpj);
loops_per_jiffy = lpj;
printed = true;
--
1.8.2.2
Hi Will,
On 05/03/2013 01:35 PM, Will Deacon wrote:
> Hi all,
>
> This small patch set may look a little over a month late, but there is a
> serious reason for posting it.
>
> When I moved the ARM delay loop over to using the architected timers
> rather than the CPU spinning loop (which has all the problems associated
> with cpu frequency scaling and what-not) I thought I was doing something
> useful for the port. However, it turns out that a surprising number of
> people have complained, and continue to complain, about the drop in
> their `BogoMIPs score'.
Have you considered adding the old code back in, but in a form that's not at
all referenced by the delay loop code and just calculates CPU-based bogomips?
Regards,
Christopher
--
Employee of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted by the Linux Foundation.
Hi!
> Now that we support a timer-backed delay loop, I'm quickly getting sick
> and tired of people complaining that their beloved bogomips value has
> decreased. You know who you are!
> Unfortunately, we can't just remove the entry from /proc/cpuinfo, as it
> will likely break fragile userspace code which is parsing that stuff, so
> instead replace it with a dummy value that can be chosen in the
> Kconfig.
So, instead of removing it you silently report invalid value? Note
that there's no cpumhz display in procinfo... at least on OLPC I
looked.
And whether it is 30MHz or 3GHz cpu might be relevant information for
userspace, and yes, bogomips used to be good enough for that.
Actually it was mhz, mhz/2 or mhz*2 on pretty much all reasonable systems.
> +choice
> + prompt "BogoMIPs setting"
> + default BOGOMIPS_MEDIUM
> + help
> + The BogoMIPs value reported by Linux is exactly what it sounds
> + like: totally bogus. It is used to calibrate the delay loop,
> + which may be backed by a timer clocked completely independently
> + of the CPU.
This is too ugly to live, sorry.
> + config BOGOMIPS_SLOW
> + bool "Slow (older machines)"
> + help
> + If you're comparing a faster machine with a slower machine,
> + then you might want this option selected on one of them.
> +
> + config BOGOMIPS_MEDIUM
> + bool "Medium (default)"
> + help
> + A BogoMIPS value for the masses.
> +
> + config BOGOMIPS_FAST
> + bool "Fast (marketing)"
> + help
> + Some people believe that software runs faster with this
> + setting so, if you're one of them, say Y here.
April 1st came late this year?
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
On 07/05/13 00:16, Pavel Machek wrote:
Hi Pawel,
>> Now that we support a timer-backed delay loop, I'm quickly getting sick
>> and tired of people complaining that their beloved bogomips value has
>> decreased. You know who you are!
>
>> Unfortunately, we can't just remove the entry from /proc/cpuinfo, as it
>> will likely break fragile userspace code which is parsing that stuff, so
>> instead replace it with a dummy value that can be chosen in the
>> Kconfig.
>
> So, instead of removing it you silently report invalid value? Note
Removing it would be an ABI breakage. Unfortunately.
> that there's no cpumhz display in procinfo... at least on OLPC I
> looked.
And? What does the CPU frequency bring you when any modern CPU has some
kind of cpufreq support that renders this information information pretty
much meaningless?
> And whether it is 30MHz or 3GHz cpu might be relevant information for
> userspace, and yes, bogomips used to be good enough for that.
Name one userspace application that extracts meaningful information out
of the BogoMIPS field. Just one.
> Actually it was mhz, mhz/2 or mhz*2 on pretty much all reasonable systems.
So any number within a ratio from one to four is good enough for you?
Wow. That pretty much proves the usefulness of this patch.
Additionally, having switched arch_timer capable CPUs to a timer based
delay instead of a loop-based delay means your precious pseudo-frequency
is now a thing of the past. And guess what? Nothing broke so far.
Because using BogoMIPS to deduct anything is *bogus*.
Timer-based delay calibration has been around for about ages. I still
remember the day (some 10 or 12 years ago) when DaveM switched the
UltraSPARC port to use the timer, and my BogoMIPS went from ~1000 to 12.
People moaned, DaveM held his position, and nothing happened. *Nothing*.
End of story.
M.
--
Jazz is not dead. It just smells funny...
On Mon, May 06, 2013 at 07:01:23PM +0100, Christopher Covington wrote:
> Hi Will,
>
> On 05/03/2013 01:35 PM, Will Deacon wrote:
> > Hi all,
> >
> > This small patch set may look a little over a month late, but there is a
> > serious reason for posting it.
> >
> > When I moved the ARM delay loop over to using the architected timers
> > rather than the CPU spinning loop (which has all the problems associated
> > with cpu frequency scaling and what-not) I thought I was doing something
> > useful for the port. However, it turns out that a surprising number of
> > people have complained, and continue to complain, about the drop in
> > their `BogoMIPs score'.
>
> Have you considered adding the old code back in, but in a form that's not at
> all referenced by the delay loop code and just calculates CPU-based bogomips?
That seems like a lot of effort in order to preserve something that isn't
even meaningful. We might be better just zeroing the value, but then we'll
inevitably get bug reports of it being `wrong'.
Plus, the calibration during boot introduces a brief delay when onlining
each core whereas this can be skipped when using a constant timer.
Will
On 05/07/2013 05:08 AM, Will Deacon wrote:
> On Mon, May 06, 2013 at 07:01:23PM +0100, Christopher Covington wrote:
>> Hi Will,
>>
>> On 05/03/2013 01:35 PM, Will Deacon wrote:
>>> Hi all,
>>>
>>> This small patch set may look a little over a month late, but there is a
>>> serious reason for posting it.
>>>
>>> When I moved the ARM delay loop over to using the architected timers
>>> rather than the CPU spinning loop (which has all the problems associated
>>> with cpu frequency scaling and what-not) I thought I was doing something
>>> useful for the port. However, it turns out that a surprising number of
>>> people have complained, and continue to complain, about the drop in
>>> their `BogoMIPs score'.
>>
>> Have you considered adding the old code back in, but in a form that's not at
>> all referenced by the delay loop code and just calculates CPU-based bogomips?
>
> That seems like a lot of effort in order to preserve something that isn't
> even meaningful. We might be better just zeroing the value, but then we'll
> inevitably get bug reports of it being `wrong'.
If I were in to filing bug reports about bogomips values, I would be just as
likely to do it for 1, 10000, 99999, and get_random_bytes(...) as for 0.
> Plus, the calibration during boot introduces a brief delay when onlining
> each core whereas this can be skipped when using a constant timer.
If it were configurable, that might give people a reason to weigh whether they
really cared about knowing bogomips at the cost of boot time.
Christopher
--
Employee of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted by the Linux Foundation.
Hello Christopher,
On Tue, May 07, 2013 at 04:48:26PM +0100, Christopher Covington wrote:
> On 05/07/2013 05:08 AM, Will Deacon wrote:
> > That seems like a lot of effort in order to preserve something that isn't
> > even meaningful. We might be better just zeroing the value, but then we'll
> > inevitably get bug reports of it being `wrong'.
>
> If I were in to filing bug reports about bogomips values, I would be just as
> likely to do it for 1, 10000, 99999, and get_random_bytes(...) as for 0.
That's a fair point, and one of the reasons I posted this as an RFC. I'd
basically like an `obviously bogus' value so that people don't think `hey,
my CPU sure it slow' and instead think `looks like this really is a bogus
value after all'.
However, you're probably right that there isn't a number which can convey
that information properly, so how about we just put a string in there along
the lines of "not reported" and leave it at that?
Will
Hi Will,
On 05/08/2013 05:06 AM, Will Deacon wrote:
> Hello Christopher,
>
> On Tue, May 07, 2013 at 04:48:26PM +0100, Christopher Covington wrote:
>> On 05/07/2013 05:08 AM, Will Deacon wrote:
>>> That seems like a lot of effort in order to preserve something that isn't
>>> even meaningful. We might be better just zeroing the value, but then we'll
>>> inevitably get bug reports of it being `wrong'.
>>
>> If I were in to filing bug reports about bogomips values, I would be just as
>> likely to do it for 1, 10000, 99999, and get_random_bytes(...) as for 0.
>
> That's a fair point, and one of the reasons I posted this as an RFC. I'd
> basically like an `obviously bogus' value so that people don't think `hey,
> my CPU sure it slow' and instead think `looks like this really is a bogus
> value after all'.
>
> However, you're probably right that there isn't a number which can convey
> that information properly, so how about we just put a string in there along
> the lines of "not reported" and leave it at that?
That sounds reasonable to me.
Christopher
--
Employee of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted by the Linux Foundation.
[ Yes, I'm late to the party ]
On Tue, 7 May 2013, Marc Zyngier wrote:
> On 07/05/13 00:16, Pavel Machek wrote:
>
> Hi Pawel,
>
> >> Now that we support a timer-backed delay loop, I'm quickly getting sick
> >> and tired of people complaining that their beloved bogomips value has
> >> decreased. You know who you are!
> >
> >> Unfortunately, we can't just remove the entry from /proc/cpuinfo, as it
> >> will likely break fragile userspace code which is parsing that stuff, so
> >> instead replace it with a dummy value that can be chosen in the
> >> Kconfig.
> >
> > So, instead of removing it you silently report invalid value? Note
>
> Removing it would be an ABI breakage. Unfortunately.
Did you really write this with a straight face?
> Name one userspace application that extracts meaningful information out
> of the BogoMIPS field. Just one.
Waitaminute... Didn't you just claim this would be an ABI break?
So if no application can be found, where is the ABI breakage?
This thread must be a joke. Please just kill the damn thing out of
/proc/cpuinfo and see if any application notices. And if some do then
they are already broken *today* and should be fixed.
Nicolas
On Tue, May 14, 2013 at 2:54 PM, Nicolas Pitre <[email protected]> wrote:
> [ Yes, I'm late to the party ]
>
> On Tue, 7 May 2013, Marc Zyngier wrote:
>
>> On 07/05/13 00:16, Pavel Machek wrote:
>>
>> Hi Pawel,
>>
>> >> Now that we support a timer-backed delay loop, I'm quickly getting sick
>> >> and tired of people complaining that their beloved bogomips value has
>> >> decreased. You know who you are!
>> >
>> >> Unfortunately, we can't just remove the entry from /proc/cpuinfo, as it
>> >> will likely break fragile userspace code which is parsing that stuff, so
>> >> instead replace it with a dummy value that can be chosen in the
>> >> Kconfig.
>> >
>> > So, instead of removing it you silently report invalid value? Note
>>
>> Removing it would be an ABI breakage. Unfortunately.
>
> Did you really write this with a straight face?
>
>> Name one userspace application that extracts meaningful information out
>> of the BogoMIPS field. Just one.
>
> Waitaminute... Didn't you just claim this would be an ABI break?
>
> So if no application can be found, where is the ABI breakage?
lscpu
But that is already "broken" on ARM because x86 uses "bogomips" and
ARM uses "BogoMIPS". I agree reporting BogoMIPS is silly, but there
are more differences between x86 and ARM. Somewhat meaningful fields
like "cpu MHz" are missing on ARM for example. These are mainly useful
for h/w inventory use which server folks tend to care about.
> This thread must be a joke. Please just kill the damn thing out of
> /proc/cpuinfo and see if any application notices. And if some do then
> they are already broken *today* and should be fixed.
And please do so for all arches then.
Rob
On Tue, 14 May 2013, Rob Herring wrote:
> On Tue, May 14, 2013 at 2:54 PM, Nicolas Pitre <[email protected]> wrote:
> > [ Yes, I'm late to the party ]
> >
> > On Tue, 7 May 2013, Marc Zyngier wrote:
> >
> >> On 07/05/13 00:16, Pavel Machek wrote:
> >>
> >> Hi Pawel,
> >>
> >> >> Now that we support a timer-backed delay loop, I'm quickly getting sick
> >> >> and tired of people complaining that their beloved bogomips value has
> >> >> decreased. You know who you are!
> >> >
> >> >> Unfortunately, we can't just remove the entry from /proc/cpuinfo, as it
> >> >> will likely break fragile userspace code which is parsing that stuff, so
> >> >> instead replace it with a dummy value that can be chosen in the
> >> >> Kconfig.
> >> >
> >> > So, instead of removing it you silently report invalid value? Note
> >>
> >> Removing it would be an ABI breakage. Unfortunately.
> >
> > Did you really write this with a straight face?
> >
> >> Name one userspace application that extracts meaningful information out
> >> of the BogoMIPS field. Just one.
> >
> > Waitaminute... Didn't you just claim this would be an ABI break?
> >
> > So if no application can be found, where is the ABI breakage?
>
> lscpu
>
> But that is already "broken" on ARM because x86 uses "bogomips" and
> ARM uses "BogoMIPS".
So basically it won't be any more broken if the field disappears
entirely, right?
> I agree reporting BogoMIPS is silly, but there
> are more differences between x86 and ARM. Somewhat meaningful fields
> like "cpu MHz" are missing on ARM for example. These are mainly useful
> for h/w inventory use which server folks tend to care about.
So... the tool must be coping well with missing fields already? If
/proc/cpuinfo is missing "important" fields on ARM then this is a
different issue.
> > This thread must be a joke. Please just kill the damn thing out of
> > /proc/cpuinfo and see if any application notices. And if some do then
> > they are already broken *today* and should be fixed.
>
> And please do so for all arches then.
Why? It happens that the bogomips reporting on ARM is even more
"broken" than on other architectures and therefore it deserves to be
removed even more than on other architectures. Who knows, maybe it
still has some semblance of a meaning on those other architectures and
that should be up to their respective maintainers to decide.
Nicolas
Hi Nico,
On Wed, May 15, 2013 at 12:56:51AM +0100, Nicolas Pitre wrote:
> On Tue, 14 May 2013, Rob Herring wrote:
> > On Tue, May 14, 2013 at 2:54 PM, Nicolas Pitre <[email protected]> wrote:
> > > Waitaminute... Didn't you just claim this would be an ABI break?
> > >
> > > So if no application can be found, where is the ABI breakage?
> >
> > lscpu
> >
> > But that is already "broken" on ARM because x86 uses "bogomips" and
> > ARM uses "BogoMIPS".
>
> So basically it won't be any more broken if the field disappears
> entirely, right?
It's not these sort of tools I was worried about. I was thinking about the
possibility of badly written parsers which want some other field from
cpuinfo, but use the bogomips line for context. Do these applications exist?
No idea.
My second (less stupid) version of the patch prints "not reported". I'd be
happy to remove the line altogether if people get behind the decision though.
In fact, I just tried it and at least my linaro filesystem seems happy
enough.
Will
On Wed 2013-05-15 10:01:03, Will Deacon wrote:
> Hi Nico,
>
> On Wed, May 15, 2013 at 12:56:51AM +0100, Nicolas Pitre wrote:
> > On Tue, 14 May 2013, Rob Herring wrote:
> > > On Tue, May 14, 2013 at 2:54 PM, Nicolas Pitre <[email protected]> wrote:
> > > > Waitaminute... Didn't you just claim this would be an ABI break?
> > > >
> > > > So if no application can be found, where is the ABI breakage?
> > >
> > > lscpu
> > >
> > > But that is already "broken" on ARM because x86 uses "bogomips" and
> > > ARM uses "BogoMIPS".
> >
> > So basically it won't be any more broken if the field disappears
> > entirely, right?
>
> It's not these sort of tools I was worried about. I was thinking about the
> possibility of badly written parsers which want some other field from
> cpuinfo, but use the bogomips line for context. Do these applications exist?
> No idea.
Yes, they do. bogomips is not nearly as bogus as you imply.
See
http://www.clifton.nl/index.html?bogomips.html
https://play.google.com/store/apps/details?id=com.securiteinfo.android.bogomips&hl=en
> My second (less stupid) version of the patch prints "not reported". I'd be
> happy to remove the line altogether if people get behind the decision though.
> In fact, I just tried it and at least my linaro filesystem seems happy
> enough.
Would it be too much work to simply put the field back with the right
value? We don't have to get it as precise as we used to, that should
make slowdown minimum.
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
On Wed, 15 May 2013, Pavel Machek wrote:
> On Wed 2013-05-15 10:01:03, Will Deacon wrote:
> > My second (less stupid) version of the patch prints "not reported".
Even then, you should tell the truth and say "not available" or "not
applicable".
> > I'd be happy to remove the line altogether if people get behind the
> > decision though.
You certainly have my ACK.
> > In fact, I just tried it and at least my linaro filesystem seems happy
> > enough.
>
> Would it be too much work to simply put the field back with the right
> value? We don't have to get it as precise as we used to, that should
> make slowdown minimum.
There is simply no right value. And whenever there is a value, people
read too much into it.
Nicolas
Hi!
> > > In fact, I just tried it and at least my linaro filesystem seems happy
> > > enough.
> >
> > Would it be too much work to simply put the field back with the right
> > value? We don't have to get it as precise as we used to, that should
> > make slowdown minimum.
>
> There is simply no right value. And whenever there is a value, people
> read too much into it.
You are right that there is no right value. But there are many _wrong_
values.
Take a look at CPU temperature. There's no right value there, either,
as CPU has different temperatures at different places. Displaying
heatsink temp +5C is probably ok. Displaying case temperature or
compile time constant is not.
Now, bogoMIPS is supposed to be instructions per second. Measure
instructions per second, and you have acceptable value to display. Put
back code from previous version, and you have acceptable value to
display.
"0", "1" or value from Kconfig is _not_ acceptable value.
Maybe bogomips should not have been exposed in /proc in the first
place, but it is too late now. "No regressions".
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html