All of lore.kernel.org
 help / color / mirror / Atom feed
From: Geoff Levand <geoffrey.levand@am.sony.com>
To: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: linuxppc-dev@ozlabs.org, David Gibson <david@gibson.dropbear.id.au>
Subject: Re: [PATCH 3/3] zImage: Cleanup and improve zImage entry point
Date: Mon, 19 Feb 2007 13:14:50 -0800	[thread overview]
Message-ID: <45DA134A.2030602@am.sony.com> (raw)
In-Reply-To: <1171918206.18571.66.camel@localhost.localdomain>

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

  reply	other threads:[~2007-02-19 21:15 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-02-16  6:24 [0/3] RFC: Cleanups and improvements to the zImage wrapper David Gibson
2007-02-16  6:27 ` [PATCH 2/3] zImage: Cleanup and improve prep_kernel() David Gibson
2007-02-18  1:22   ` Geoff Levand
2007-02-18  7:21     ` David Gibson
2007-02-16  6:27 ` [PATCH 1/3] zImage: Add more flexible gunzip convenience functions David Gibson
2007-02-16  6:27 ` [PATCH 3/3] zImage: Cleanup and improve zImage entry point David Gibson
2007-02-18  1:22   ` Geoff Levand
2007-02-18  7:23     ` David Gibson
2007-02-19  0:26       ` Paul Mackerras
2007-02-19  0:48         ` David Gibson
2007-02-19 15:14       ` Geoff Levand
2007-02-19 19:59         ` Benjamin Herrenschmidt
2007-02-19 19:57     ` Benjamin Herrenschmidt
2007-02-19 20:37       ` Geoff Levand
2007-02-19 20:50         ` Benjamin Herrenschmidt
2007-02-19 21:14           ` Geoff Levand [this message]
2007-02-16 16:47 ` [0/3] RFC: Cleanups and improvements to the zImage wrapper Geoff Levand

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=45DA134A.2030602@am.sony.com \
    --to=geoffrey.levand@am.sony.com \
    --cc=benh@kernel.crashing.org \
    --cc=david@gibson.dropbear.id.au \
    --cc=linuxppc-dev@ozlabs.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.