Re: [PATCH 1/2] boot: increase stack size for kernel boot loader decompressor

[Mike Travis <travis@sgi.com>]

Ingo Molnar wrote:
> * Mike Travis <travis@sgi.com> wrote:
> 
>> Ingo Molnar wrote:
>>> * Alexander van Heukelum <heukelum@mailshack.com> wrote:
>>>
>>>> Hi Ingo,
>>>>
>>>> I see you have applied the following patch to x86#for-akpm. It was 
>>>> really ment for testing only. I think you ment to use this one 
>>>> instead?
>>> yep, i wanted to see how it holds up in testing - it's OK so far. I've 
>>> got your other, fuller one queued up meanwhile - it's not pushed out 
>>> yet.
>>>
>>> 	Ingo
>> I will try it out on my failing case as soon as I can...
> 
> more test results: i just booted an allyesconfig 64-bit (MAXSMP, etc.) 
> kernel on x86 native hardware successfully - that has Alexander's patch 
> included but not your boot tweak. (has all your other patches included)
> 
> would you expect a real 4K CPUs system to boot any differently? So early 
> during bootup all x86 hardware is just a uniprocessor, so i'd be 
> surprised if there was any difference.
> 
> [ in any case, if the tweak still makes a real difference for you we can 
>   still apply it because it does not hurt anyone - but lets try to avoid 
>   black voodoo tweaks as much as possible :) ]

Yes, my patch is not needed.  I booted the akpm2 config with 512 possible
cpus (8 real) on an Intel box with 8gig total ram.  It booted fine and is
running some cpuset and sched-domain tests now.

One problem though, even though it has slots for extra cpus to be brought
online there is no /sys/devices/cpu/cpuXX/online file to actually bring
them online.  This was shown in a simulated run I did with 64 real cpus
and 12 of them disabled.  They showed up in the 'possible' map but no
way to bring them online.  [Unless there's a trick I don't know about.
Nothing is mentioned in Documentation/cpu-hotplug.txt about this.]

> 
> btw,. booting up MAXSMP is pretty impressive:
> 
>   CONFIG_NR_CPUS=4096
> 
> shows how far Linux scalability has come :)
> 
> i've got a bugreport for you though: MAXSMP does not suspend+resume 
> correctly ;-) It gets this far:
> 
> [  146.348790] PM: Syncing filesystems ... done.
> [  146.353488] PM: Preparing system for mem sleep
> [  146.360204] Freezing user space processes ... (elapsed 0.00 seconds) done.
> [  146.367172] Freezing remaining freezable tasks ... (elapsed 0.93 seconds) done.
> [  147.309618] PM: Entering mem sleep
> [  147.313032] Suspending console(s)
> 
> then reboots spontaneously instead of resuming. (I use the 
> suspend+resume self-test feature below to conduct automated 
> suspend/resume tests.)
> 
> 	Ingo

I will try it out.  Yes, please send me any tests I can add to my suite.

Thanks!
Mike