Re: [PATCH -mm] extend sysrq-p functionality to cover all CPUs

[Andrew Morton]

On Mon, 10 Mar 2008 09:30:24 -0400 Rik van Riel <riel@xxxxxxxxxxx> wrote:

> On Sun, 9 Mar 2008 22:47:59 -0700
> Andrew Morton <akpm@xxxxxxxxxxxxxxxxxxxx> wrote:
> 
> > On Sun, 9 Mar 2008 22:14:58 -0400 Rik van Riel <riel@xxxxxxxxxxx> wrote:
> > 
> > > SysRP-P is not all that useful on SMP systems, since the sysrq
> > > irq rarely ends up on the CPU that we actually want to investigate.
> 
> > Doesn't everyone have a copy of this somewhere? ;)
> 
> Yes, but the old version of the patch calls on_each_cpu from
> sysrq context, which is illegal since it could cause a deadlock.

My version did queue_work(), iirc, but I seem to have lost it.

I have an old patch here from Brice Goglin which does it via an NMI, but
that's arch-specific, I guess.

afaict, we _could_ implement an IPI call which isn't deadlockable (on x86,
at least) if we were to make it an asynchronous one.

Even if the hardware doesn't support queueing, this could still be done in
software via suitable locking and software queueing.

Whatever.

> > However it does have the downside that info can scroll away on large cpu
> > counts.  Maybe it should be a new sysrq command?
> 
> It used to be sysrq-w in the patches that everybody has, but that
> letter got taken for sysrq_showstate_blocked_op.
> 
> Only sysrq h, j, l, y and z are still free.  H is needed for help,
> leaving just j, l, y and z.
> 
> I can see your point about overflowing the screen,

iirc, this was the reason for not doing this years ago.  I don't know how
real that is.

> however just
> sysrq-p seems like a waste to have because it will probably not
> print anything useful on a large CPU system...

Yeah, sometimes it helps to keep hitting it until you get the right CPU,
but that rather depends on interrupt distribution.

It would be neat to suppress the trace for idle CPUs.  I don't _think_
there's a need to display the trace for idle CPUs in sysrq-P?

> If you still want it to be a separate letter, just let me know
> which one of the last four I should take.

l :)
--
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/