[PATCH 3/3] zImage: Cleanup and improve zImage entry point

Geoff Levand geoffrey.levand at am.sony.com
Tue Feb 20 08:14:50 EST 2007


Benjamin Herrenschmidt wrote:
> On Mon, 2007-02-19 at 12:37 -0800, Geoff Levand wrote:
>> Benjamin Herrenschmidt wrote:
>> >> This messed me up a bit since I had two stacks in the bss, one for each
>> >> processor thread.  By the time this was called on the primary thread the
>> >> secondary thread could already be using its stack.  I changed the secondary
>> >> thread to use a small stack in the data section, so this seems OK.
>> > 
>> > The secondary thread(s) don't need a stack to loop in secondary hold,
>> > right ? So maybe we could go all the way without using a stack. Do we
>> > need C code at all for them ? We just need to hold them until we make
>> > them branch to the kernel.
>> 
>> I thought it would be nice to be able to use printf() in there so you
>> see the following.  Its handy for debugging.
>> 
>> smp_secondary_hold:307: released cpu (1)
> 
> The problem is if your secondary CPUs start using printf etc... that
> means you probably need to get in some locking primitives and make
> various bits of the zImage wrapper SMP safe... pretty scary don't you
> think ? :-)

If you want to make it idiot proof, yes, but I was thinking more that
smp_secondary_hold just prints a final debug message after the primary
is done.  It does cause problems if there are more than one secondary.

> I'd rather leave all non-0 CPUs in an asm holding loop. However, you can
> still print some status. One of the ideas is to have them fill up a
> byte-map of present CPUs when they get in the holding loop, then the
> main CPU can "see" them coming in and print something.

I was more interested in seeing that the secondary left smp_secondary_hold,
not that it entered it.  I don't really want to add the complexity to make
the primary wait for the secondaries to exit and then print a message.

-Geoff





More information about the Linuxppc-dev mailing list