Skip to contentSkip to conversation

init: support preset lpj value as config option

PATCH In review Tim Bird 5 participants 7 messages Jan 25, 2007 – Jan 26, 2007

lore
Share & tools
lore

Tim Bird

author
#0 lore raw

PATCH 1/1 init: support preset lpj value as config option

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.

----

init/Kconfig +29 -0
diff -pruN linux-2.6.20-rc5-git2.orig/init/Kconfig linux-2.6.20-rc5-git2/init/Kconfig
@@ -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
init/calibrate.c +1 -1
diff -pruN linux-2.6.20-rc5-git2.orig/init/calibrate.c linux-2.6.20-rc5-git2/init/calibrate.c
@@ -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);
#1 lore raw
Quoted 4 lines · Tim Bird

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.

author
#2 lore raw
Quoted 11 lines · Paul Mundt
Quoted 4 lines · Tim Bird

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
=============================

#3 lore raw
Quoted 13 lines · On Thu, 25 Jan 2007 10:24:59 -0800 Tim Bird <[email protected]> wrote:
Quoted 11 lines · Paul Mundt
Quoted 4 lines · Tim Bird

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.

Quoted 2 lines

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.

Quoted 4 lines

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?

author
#4 lore raw
Quoted 11 lines · Andrew Morton
Quoted 2 lines

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.

Quoted 4 lines

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.

Quoted 5 lines

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
=============================

#5 lore raw
Quoted 24 lines · Tim Bird
Quoted 11 lines · Andrew Morton
Quoted 2 lines

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.

Quoted 4 lines

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.

Quoted 5 lines

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

Quoted 7 lines

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.

Signature · 1 line
Mathematics is the supreme nostalgia of our time.
#6 lore raw
Quoted 11 lines · Matt Mackall

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