On Mon, 11 Jun 2007 15:32:10 +0100 Andy Whitcroft <[email protected]> wrote:
>
> We are seeing corruption of the decompressed kernel. It is suspected
> that this is platform specific as it has yet to be seen on any
> other x86. Move the kernel to the 16MB boundary.
>
> Signed-off-by: Andy Whitcroft <[email protected]>
> ---
> diff --git a/arch/i386/Kconfig b/arch/i386/Kconfig
> index 7e1950f..89e6bf4 100644
> --- a/arch/i386/Kconfig
> +++ b/arch/i386/Kconfig
> @@ -817,6 +817,7 @@ config CRASH_DUMP
>
> config PHYSICAL_START
> hex "Physical address where the kernel is loaded" if (EMBEDDED || CRASH_DUMP)
> + default "0x1000000" if X86_NUMAQ
> default "0x100000"
> help
> This gives the physical address where the kernel is loaded.
grumble. If it's a BIOS bug then OK. But if it is indeed a kernel bug
then this patch didn't make it go away and it shall return to haunt us.
Oh well. Let's hope that the bug (if it is such) will turn up on something
which is less debugging-hostile than a NUMAQ.
On Mon, Jun 11, 2007 at 09:15:58AM -0700, Andrew Morton wrote:
> On Mon, 11 Jun 2007 15:32:10 +0100 Andy Whitcroft <[email protected]> wrote:
>
> >
> > We are seeing corruption of the decompressed kernel. It is suspected
> > that this is platform specific as it has yet to be seen on any
> > other x86. Move the kernel to the 16MB boundary.
> >
> > Signed-off-by: Andy Whitcroft <[email protected]>
> > ---
> > diff --git a/arch/i386/Kconfig b/arch/i386/Kconfig
> > index 7e1950f..89e6bf4 100644
> > --- a/arch/i386/Kconfig
> > +++ b/arch/i386/Kconfig
> > @@ -817,6 +817,7 @@ config CRASH_DUMP
> >
> > config PHYSICAL_START
> > hex "Physical address where the kernel is loaded" if (EMBEDDED || CRASH_DUMP)
> > + default "0x1000000" if X86_NUMAQ
> > default "0x100000"
> > help
> > This gives the physical address where the kernel is loaded.
>
> grumble. If it's a BIOS bug then OK. But if it is indeed a kernel bug
> then this patch didn't make it go away and it shall return to haunt us.
FWIW, waay back when (sometime last year if memory serves)
Linus suggested changing the default to 0x1000000 for all x86.
The reasoning was some performance microoptimisation regarding
4MB aligned TLBs iirc.
The details have long since evaded my memory, but as an experiment,
I made the change to the Fedora kernel. FC5,FC6 and F7 have been
this way for a while now, with no obvious problems. Ditto RHEL5.
We did get some performance numbers at the time of the change,
but they weren't amazing (basically in the noise).
Given it never seemed to actually get worse, I never got around
to reverting it..
Dave
--
http://www.codemonkey.org.uk
Dave Jones wrote:
>
> FWIW, waay back when (sometime last year if memory serves)
> Linus suggested changing the default to 0x1000000 for all x86.
> The reasoning was some performance microoptimisation regarding
> 4MB aligned TLBs iirc.
>
> The details have long since evaded my memory, but as an experiment,
> I made the change to the Fedora kernel. FC5,FC6 and F7 have been
> this way for a while now, with no obvious problems. Ditto RHEL5.
> We did get some performance numbers at the time of the change,
> but they weren't amazing (basically in the noise).
> Given it never seemed to actually get worse, I never got around
> to reverting it..
>
Picking the 16 MB base is a bit obnoxious on small-memory machines, 4 MB
would probably be a more reasonable base. Of course, 16 MB would avoid
the issue of the handful of machines with memory holes at 15-16 MB.
-hpa
On 06/11/2007 07:20 PM, Dave Jones wrote:
> FWIW, waay back when (sometime last year if memory serves)
> Linus suggested changing the default to 0x1000000 for all x86.
> The reasoning was some performance microoptimisation regarding
> 4MB aligned TLBs iirc.
Yup. Or rather, he suggested 4M (0x400000):
http://lkml.org/lkml/2006/2/23/189
Aligning the kernel image on 4M could gain an additional TLB entry if the
kernel image would fit in one (4M aligned) hugepage, but not in the 3M
that's left after loading the kernel at 1M physical. And that stuff about
the MTRRs...
That 0x1000000 (16M) is another potentially interesting value on machines
with enough memory as it gets the kernel image out of the old ZONE_DMA.
> The details have long since evaded my memory, but as an experiment,
> I made the change to the Fedora kernel. FC5,FC6 and F7 have been
> this way for a while now, with no obvious problems. Ditto RHEL5.
> We did get some performance numbers at the time of the change,
> but they weren't amazing (basically in the noise).
> Given it never seemed to actually get worse, I never got around
> to reverting it..
I've been loading the kernel at 16M physical for ages now on x86. No
problems either.
Rene.
Rene Herman wrote:
>
> Aligning the kernel image on 4M could gain an additional TLB entry if
> the kernel image would fit in one (4M aligned) hugepage, but not in the
> 3M that's left after loading the kernel at 1M physical. And that stuff
> about the MTRRs...
>
Yup. Most CPUs won't actually use a largepage for the kernel if it's
below 4 MB (2 MB with PAE, so that's what x86-64 uses.)
-hpa
On 06/11/2007 07:58 PM, H. Peter Anvin wrote:
> Rene Herman wrote:
>> Aligning the kernel image on 4M could gain an additional TLB entry if
>> the kernel image would fit in one (4M aligned) hugepage, but not in the
>> 3M that's left after loading the kernel at 1M physical. And that stuff
>> about the MTRRs...
>>
>
> Yup. Most CPUs won't actually use a largepage for the kernel if it's
> below 4 MB (2 MB with PAE, so that's what x86-64 uses.)
Oh, thanks, that's interesting. Had no idea. In those cases it would seem to
at least potentially be a serious performance issue.
Rene.
On Jun 11 2007 10:36, H. Peter Anvin wrote:
>
>Picking the 16 MB base is a bit obnoxious on small-memory machines, 4 MB
>would probably be a more reasonable base. Of course, 16 MB would avoid
> the issue of the handful of machines with memory holes at 15-16 MB.
How will this work at all with a 5 MB machine?
Jan
--
On Mon, Jun 11, 2007 at 08:19:57PM +0200, Jan Engelhardt wrote:
>
> On Jun 11 2007 10:36, H. Peter Anvin wrote:
> >
> >Picking the 16 MB base is a bit obnoxious on small-memory machines, 4 MB
> >would probably be a more reasonable base. Of course, 16 MB would avoid
> > the issue of the handful of machines with memory holes at 15-16 MB.
>
> How will this work at all with a 5 MB machine?
Unless you're running with a bunch of CONFIG_EMBEDDED options enabled,
and a seriously pared down (almost to the point of uselessness)
userspace, you may have already lost.
Do such beasts even exist ? My memories of low-memory x86en I had
only allowed power of 2 memory sizes.
Dave
--
http://www.codemonkey.org.uk
Jan Engelhardt wrote:
> On Jun 11 2007 10:36, H. Peter Anvin wrote:
>> Picking the 16 MB base is a bit obnoxious on small-memory machines, 4 MB
>> would probably be a more reasonable base. Of course, 16 MB would avoid
>> the issue of the handful of machines with memory holes at 15-16 MB.
>
> How will this work at all with a 5 MB machine?
Does current kernels work at all on a 5 MB machine?
(I used Linux on a 5 MB machine many years ago, but modern kernels are a
different issue...)
-hpa
> Do such beasts even exist ? My memories of low-memory x86en I had
> only allowed power of 2 memory sizes.
They existed. If you had two memory banks you could load 4MB and 1MB. If
you had a single set of memory sockets then you got powers of two
diff --git a/arch/i386/Kconfig b/arch/i386/Kconfig
index 8770a5d..6737529 100644
--- a/arch/i386/Kconfig
+++ b/arch/i386/Kconfig
@@ -813,9 +813,10 @@ config CRASH_DUMP
PHYSICAL_START.
For more details see Documentation/kdump/kdump.txt
-config PHYSICAL_START
- hex "Physical address where the kernel is loaded" if (EMBEDDED || CRASH_DUMP)
- default "0x100000"
+choice
+ depends on EMBEDDED || CRASH_DUMP
+ prompt "Physical address where the kernel is loaded"
+ default PHYSICAL_START_1M
help
This gives the physical address where the kernel is loaded.
@@ -854,6 +855,40 @@ config PHYSICAL_START
Don't change this unless you know what you are doing.
+ config PHYSICAL_START_1M
+ bool "1M"
+ help
+ Choose this to load the kernel at the standard 1M address.
+
+ config PHYSICAL_START_4M
+ bool "4M"
+ help
+ Loading the kernel at a 4M aligned physical address can
+ make for a slightly faster kernel.
+
+ Choose this if you have 8M or more installed.
+
+ config PHYSICAL_START_16M
+ bool "16M"
+ help
+ Loading the kernel at a 4M aligned physical address can
+ make for a slightly faster kernel.
+
+ Additionally, loading it at 16M gets it out of the legacy
+ DMA zone which you might consider beneficial if you use
+ devices doing legacy DMA (such as a floppy drive, an ECP
+ parallel port or DMA capable ISA peripherals).
+
+ Choose this if you have 20M or more installed and a need
+ for legacy DMA.
+endchoice
+
+config PHYSICAL_START
+ hex
+ default "0x100000" if PHYSICAL_START_1M
+ default "0x400000" if PHYSICAL_START_4M
+ default "0x1000000" if PHYSICAL_START_16M
+
config RELOCATABLE
bool "Build a relocatable kernel(EXPERIMENTAL)"
depends on EXPERIMENTAL
On 06/11/2007 10:07 PM, Rene Herman wrote:
> But, it's just a default anyway. Would it be considered beneficial to
> more explicitly provide a few options through a config menu, something
> like the attached?
Ehm, so now where did that long help actually end up? :-|
If the notion is considered okay, this wants someone with a little more
Kconfig insight it seems.
> diff --git a/arch/i386/Kconfig b/arch/i386/Kconfig
> index 8770a5d..6737529 100644
> --- a/arch/i386/Kconfig
> +++ b/arch/i386/Kconfig
> @@ -813,9 +813,10 @@ config CRASH_DUMP
> PHYSICAL_START.
> For more details see Documentation/kdump/kdump.txt
>
> -config PHYSICAL_START
> - hex "Physical address where the kernel is loaded" if (EMBEDDED || CRASH_DUMP)
> - default "0x100000"
> +choice
> + depends on EMBEDDED || CRASH_DUMP
> + prompt "Physical address where the kernel is loaded"
> + default PHYSICAL_START_1M
> help
> This gives the physical address where the kernel is loaded.
>
> @@ -854,6 +855,40 @@ config PHYSICAL_START
>
> Don't change this unless you know what you are doing.
>
> + config PHYSICAL_START_1M
> + bool "1M"
> + help
> + Choose this to load the kernel at the standard 1M address.
> +
> + config PHYSICAL_START_4M
> + bool "4M"
> + help
> + Loading the kernel at a 4M aligned physical address can
> + make for a slightly faster kernel.
> +
> + Choose this if you have 8M or more installed.
> +
> + config PHYSICAL_START_16M
> + bool "16M"
> + help
> + Loading the kernel at a 4M aligned physical address can
> + make for a slightly faster kernel.
> +
> + Additionally, loading it at 16M gets it out of the legacy
> + DMA zone which you might consider beneficial if you use
> + devices doing legacy DMA (such as a floppy drive, an ECP
> + parallel port or DMA capable ISA peripherals).
> +
> + Choose this if you have 20M or more installed and a need
> + for legacy DMA.
> +endchoice
> +
> +config PHYSICAL_START
> + hex
> + default "0x100000" if PHYSICAL_START_1M
> + default "0x400000" if PHYSICAL_START_4M
> + default "0x1000000" if PHYSICAL_START_16M
> +
> config RELOCATABLE
> bool "Build a relocatable kernel(EXPERIMENTAL)"
> depends on EXPERIMENTAL
Rene.
On Jun 11 2007 12:01, H. Peter Anvin wrote:
>Jan Engelhardt wrote:
>> On Jun 11 2007 10:36, H. Peter Anvin wrote:
>>> Picking the 16 MB base is a bit obnoxious on small-memory machines, 4 MB
>>> would probably be a more reasonable base. Of course, 16 MB would avoid
>>> the issue of the handful of machines with memory holes at 15-16 MB.
>>
>> How will this work at all with a 5 MB machine?
>
>Does current kernels work at all on a 5 MB machine?
>
>(I used Linux on a 5 MB machine many years ago, but modern kernels are a
>different issue...)
Yes, I ran an unmodified 2.6.13 with a minimal but somewhat minimal
userspace (sash, glibc) on an fpu-less 386.
http://jengelh.hopto.org/GFX/mach/386sx.jpg
http://jengelh.hopto.org/GFX/mach/proc386.jpg
(yay, 3.09 bogomips and a totally incapable processor :p)
Have not tried more recent kernels yet though.
Jan
--
Jan Engelhardt wrote:
> (yay, 3.09 bogomips and a totally incapable processor :p)
> Have not tried more recent kernels yet though.
Too bad I don't still have access to the 0.59 bogomips "double sigma"
386 machine that had the dubious honor of being the slowest Linux
machine in the world for quite a while. That machine had 3 MB of RAM.
However, to tie it back to the original discussion, these
extremely-low-memory machines need nonstandard kernel options anyay.
While doing my SuperRescue disk I was able to get it down to the point
where I could successfully boot and use the system on a 24 MB machine; I
personally run a 32 MB box as a server today.
-hpa
On Jun 11 2007 13:51, H. Peter Anvin wrote:
>Jan Engelhardt wrote:
>> (yay, 3.09 bogomips and a totally incapable processor :p)
>> Have not tried more recent kernels yet though.
>
>Too bad I don't still have access to the 0.59 bogomips "double sigma"
>386 machine that had the dubious honor of being the slowest Linux
>machine in the world for quite a while. That machine had 3 MB of RAM.
>
>However, to tie it back to the original discussion, these
>extremely-low-memory machines need nonstandard kernel options anyay.
Not really. Want a .config?
Jan
--
