public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Andrew Morton <akpm@linux-foundation.org>
To: Rik van Riel <riel@surriel.com>
Cc: linux-kernel@vger.kernel.org, lwoodman@redhat.com
Subject: Re: [PATCH -mm] extend sysrq-p functionality to cover all CPUs
Date: Mon, 10 Mar 2008 09:24:13 -0700	[thread overview]
Message-ID: <20080310092413.6102c965.akpm@linux-foundation.org> (raw)
In-Reply-To: <20080310093024.55a4ff90@bree.surriel.com>

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

> On Sun, 9 Mar 2008 22:47:59 -0700
> Andrew Morton <akpm@linux-foundation.org> wrote:
> 
> > On Sun, 9 Mar 2008 22:14:58 -0400 Rik van Riel <riel@surriel.com> 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 :)

  reply	other threads:[~2008-03-10 16:26 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-03-10  2:14 [PATCH -mm] extend sysrq-p functionality to cover all CPUs Rik van Riel
2008-03-10  5:47 ` Andrew Morton
2008-03-10 13:30   ` Rik van Riel
2008-03-10 16:24     ` Andrew Morton [this message]
2008-03-10 17:03       ` Rik van Riel
2008-03-10 14:58   ` Larry Woodman

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=20080310092413.6102c965.akpm@linux-foundation.org \
    --to=akpm@linux-foundation.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=lwoodman@redhat.com \
    --cc=riel@surriel.com \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox