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

From: Mike Travis
Date: Tue Apr 08 2008 - 15:09:52 EST


Ingo Molnar wrote:
> * Mike Travis <travis@xxxxxxx> wrote:
>
>> Ingo Molnar wrote:
>>> * Alexander van Heukelum <heukelum@xxxxxxxxxxxxx> 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


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/