Often, it is useful to preserve the preset loops_per_jiffy
value for a machine in a config option. Right now, you can
specify a preset lpj value on the kernel command line. But this
means the value is preserved in the firmware, which is less
portable between developers.
This patch provides a config option for preset lpj, which means
the value can be easily preserved, and conveyed between developers
in a config file.
Signed-off-by: Tim Bird <[email protected]>
----
diff -pruN linux-2.6.20-rc5-git2.orig/init/Kconfig linux-2.6.20-rc5-git2/init/Kconfig
--- linux-2.6.20-rc5-git2.orig/init/Kconfig 2007-01-12 10:54:26.000000000 -0800
+++ linux-2.6.20-rc5-git2/init/Kconfig 2007-01-24 16:03:30.000000000 -0800
@@ -466,6 +466,35 @@ config VM_EVENT_COUNTERS
on EMBEDDED systems. /proc/vmstat will only show page counts
if VM event counters are disabled.
+config PRESET_LPJ
+ int "Preset loops_per_jiffy" if EMBEDDED
+ default 0
+ help
+ Set this to preset the number of loops used by delay() to
+ achieve a single jiffy of delay inside the kernel. This is
+ normally calculated at boot time, but that calibration can
+ take up to 250 ms per CPU. Specifying a constant value here
+ eliminates the calibration, and improves bootup time.
+
+ A value of 0 results in the normal autodetect behavior.
+
+ To determine the correct value for your kernel, first set this
+ option to 0, compile and boot the kernel on your target hardware,
+ then see what value is printed during the kernel boot. Use that
+ value here.
+
+ The kernel command line parameter "lpj=" can be used to override
+ the value configured here.
+
+ Note that on SMP systems the preset will be applied to all CPUs,
+ which could cause problems if for some reason your CPUs need
+ significantly divergent settings.
+
+ If unsure, set this to 0. An incorrect value will cause delays in
+ the kernel to be wrong, leading to unpredictable I/O errors and
+ other breakage. Although unlikely, in the extreme case this might
+ damage your hardware.
+
endmenu # General setup
config RT_MUTEXES
diff -pruN linux-2.6.20-rc5-git2.orig/init/calibrate.c linux-2.6.20-rc5-git2/init/calibrate.c
--- linux-2.6.20-rc5-git2.orig/init/calibrate.c 2007-01-12 10:54:26.000000000 -0800
+++ linux-2.6.20-rc5-git2/init/calibrate.c 2007-01-23 11:23:39.000000000 -0800
@@ -10,7 +10,7 @@
#include <asm/timex.h>
-static unsigned long preset_lpj;
+static unsigned long preset_lpj = CONFIG_PRESET_LPJ;
static int __init lpj_setup(char *str)
{
preset_lpj = simple_strtoul(str,NULL,0);
On Wed, Jan 24, 2007 at 04:12:18PM -0800, Tim Bird wrote:
> This patch provides a config option for preset lpj, which means
> the value can be easily preserved, and conveyed between developers
> in a config file.
>
This seems excessive, it's already possible to set the preset lpj on the
kernel command line, and virtually every one of the embedded
architectures supports setting the kernel command line as a config
option. Is there any reason why you can't simply set it there as a
default instead? It's all going to be .config resident in the end
anyways.
Paul Mundt wrote:
> On Wed, Jan 24, 2007 at 04:12:18PM -0800, Tim Bird wrote:
>> This patch provides a config option for preset lpj, which means
>> the value can be easily preserved, and conveyed between developers
>> in a config file.
>>
> This seems excessive, it's already possible to set the preset lpj on the
> kernel command line, and virtually every one of the embedded
> architectures supports setting the kernel command line as a config
> option. Is there any reason why you can't simply set it there as a
> default instead? It's all going to be .config resident in the end
> anyways.
i386 is missing CONFIG_CMDLINE support, and this architecture
is used in embedded. I think many other x86 derivatives are
also missing .config-based command line support. CELF has
worked to get patches submitted to fix this, but so far these
haven't been accepted.
For this reason (and IMHO from the standpoint of orthogonality)
I think it's awkward to have options which ONLY have a command-line
representation, and not a way to compile them in separately.
=============================
Tim Bird
Architecture Group Chair, CE Linux Forum
Senior Staff Engineer, Sony Electronics
=============================
On Thu, 25 Jan 2007 10:24:59 -0800
Tim Bird <[email protected]> wrote:
> Paul Mundt wrote:
> > On Wed, Jan 24, 2007 at 04:12:18PM -0800, Tim Bird wrote:
> >> This patch provides a config option for preset lpj, which means
> >> the value can be easily preserved, and conveyed between developers
> >> in a config file.
> >>
> > This seems excessive, it's already possible to set the preset lpj on the
> > kernel command line, and virtually every one of the embedded
> > architectures supports setting the kernel command line as a config
> > option. Is there any reason why you can't simply set it there as a
> > default instead? It's all going to be .config resident in the end
> > anyways.
>
> i386 is missing CONFIG_CMDLINE support, and this architecture
> is used in embedded.
So if we add CONFIG_CMDLINE we fix this problem and we bring i386 into line
with other platforms. It's all good.
> I think many other x86 derivatives are
> also missing .config-based command line support. CELF has
> worked to get patches submitted to fix this, but so far these
> haven't been accepted.
You have?
<looks at inbox>
To whom?
Andrew Morton wrote:
>> i386 is missing CONFIG_CMDLINE support, and this architecture
>> is used in embedded.
>
> So if we add CONFIG_CMDLINE we fix this problem and we bring i386 into line
> with other platforms. It's all good.
>
>> I think many other x86 derivatives are
>> also missing .config-based command line support. CELF has
>> worked to get patches submitted to fix this, but so far these
>> haven't been accepted.
>
> You have?
>
> <looks at inbox>
>
> To whom?
Matt Mackall would know better than I. He's the person
CELF hired to do this. Here are some of the previous LKML
discussions around this issue:
http://lkml.org/lkml/2006/6/11/115
http://lkml.org/lkml/2006/7/31/208
Last time I talked to Matt about this (some time in
November, I believe), he said he had worked out a
solution agreeable to H. Peter Anvin, who had issues
with the original submission. I'm not sure if that
latest solution was submitted to mainline or not.
Matt?
-- Tim
=============================
Tim Bird
Architecture Group Chair, CE Linux Forum
Senior Staff Engineer, Sony Electronics
=============================
On Fri, Jan 26, 2007 at 10:29:24AM -0800, Tim Bird wrote:
> Andrew Morton wrote:
> >> i386 is missing CONFIG_CMDLINE support, and this architecture
> >> is used in embedded.
> >
> > So if we add CONFIG_CMDLINE we fix this problem and we bring i386 into line
> > with other platforms. It's all good.
> >
> >> I think many other x86 derivatives are
> >> also missing .config-based command line support. CELF has
> >> worked to get patches submitted to fix this, but so far these
> >> haven't been accepted.
> >
> > You have?
> >
> > <looks at inbox>
> >
> > To whom?
>
> Matt Mackall would know better than I. He's the person
> CELF hired to do this. Here are some of the previous LKML
> discussions around this issue:
>
> http://lkml.org/lkml/2006/6/11/115
>
> http://lkml.org/lkml/2006/7/31/208
>
> Last time I talked to Matt about this (some time in
> November, I believe), he said he had worked out a
> solution agreeable to H. Peter Anvin, who had issues
> with the original submission. I'm not sure if that
> latest solution was submitted to mainline or not.
The idea was to allow putting something like "%s" in the built-in
command line and expanding that with the provided command line. This
allows you to append/prepend/ignore the provided command line as you
desire.
This is a fair bit more complicated than what the existing
implementations of CONFIG_CMDLINE are doing and details like
early_cmdline handling don't help matters. Haven't yet come up with an
implementation I'm happy with.
--
Mathematics is the supreme nostalgia of our time.
Matt Mackall wrote:
>
> The idea was to allow putting something like "%s" in the built-in
> command line and expanding that with the provided command line. This
> allows you to append/prepend/ignore the provided command line as you
> desire.
>
> This is a fair bit more complicated than what the existing
> implementations of CONFIG_CMDLINE are doing and details like
> early_cmdline handling don't help matters. Haven't yet come up with an
> implementation I'm happy with.
>
Yes, and it's worth noting that with the edd stuff we actually parse the
command line from real mode as well.
One way to do it would be to construct the command line in real mode
code. It's not really all that hard, but wouldn't work for those that
jump directly to the PM entrypoint.
-hpa