mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Peter Zijlstra <peterz@infradead.org>
To: Yafang Shao <laoar.shao@gmail.com>
Cc: mingo@redhat.com, gregkh@linuxfoundation.org, jslaby@suse.com,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH v3] scheduler: enhancement to show_state_filter and SysRq
Date: Wed, 9 Aug 2017 18:42:50 +0200	[thread overview]
Message-ID: <20170809164250.aza4csoc2jcwkvx7@hirez.programming.kicks-ass.net> (raw)
In-Reply-To: <CALOAHbDJ_zsUzFzSLSjRbQoi3ko7i2P2fPDFT4zdrkD=pBZg3g@mail.gmail.com>

On Wed, Aug 09, 2017 at 05:26:14PM +0800, Yafang Shao wrote:
> 2017-08-09 17:09 GMT+08:00 Peter Zijlstra <peterz@infradead.org>:
> > On Wed, Aug 09, 2017 at 04:01:49PM +0800, Yafang Shao wrote:
> >> 2017-08-09 15:43 GMT+08:00 Peter Zijlstra <peterz@infradead.org>:
> >> > On Wed, Aug 09, 2017 at 06:31:28PM +0800, Yafang Shao wrote:
> >> >> Sometimes we want to get tasks in TASK_RUNNING sepcifically,
> >> >> instead of dump all tasks.
> >> >>
> >> >> For example, when the loadavg are high, we want to dump
> >> >> tasks in TASK_RUNNING and TASK_UNINTERRUPTIBLE, which contribute
> >> >> to system load. But mostly there're lots of tasks in Sleep state,
> >> >> which occupies almost all of the kernel log buffer, even overflows
> >> >> it, that causes the useful messages get lost. Although we can
> >> >> enlarge the kernel log buffer, but that's not a good idea.
> >> >
> >> > That's what you have serial consoles for...
> >> >
> >> mostly we don't even have one console because we alwayas login the
> >> servers via ssh. And manage the servers with console is not so convenient.
> >
> > I find IPMI SOL very useful. Serial console (esp. earlyprintk) keeps on
> > working long after most other things have died.
> >
> > In any case, you can easily dump the printk output into your ssh session
> > if you want, use something like:
> >
> >         cat /dev/kmsg | tee logfile & echo t > /proc/sysrq-trigger
> 
> that's what I'm doing it currently :)
> Then I thought deeply why not do it more smartly?
> Introducing a new key(here I just modified the key 'w') only dump
> tasks in running and blocked should be more smarter.

Since you're strictly ssh based, you could maybe do a sysctl that allows
changing the 'default' filter of sysctl-t, dunno if that makes sense
though.

Also, since you're not actually debugging a dead machine, maybe you can
do a custom kernel module / systemtap / ebpf thing that collects
precisely the information you want.

sysrq is typically a last ditch debug mostly dead machine thing, which
you're very much not having.

> >
> > I really see no problem here. Then you can run a bit of awk or whatever
> > your favourite tool is to filter out the stuff you don't want.
> >
> Another question, if we could filter with scritpts in userland, why
> did we introduced the key 'w' to dump only blocked state
> as we already have a key 't' to dump all tasks ?

No idea that is long before my time, I expect because 'w' (blocked) is
typically a small number of tasks.

  reply	other threads:[~2017-08-09 16:43 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-08-09 10:31 Yafang Shao
2017-08-09  7:43 ` Peter Zijlstra
2017-08-09  8:01   ` Yafang Shao
2017-08-09  9:09     ` Peter Zijlstra
2017-08-09  9:26       ` Yafang Shao
2017-08-09 16:42         ` Peter Zijlstra [this message]
2017-08-10  2:44           ` Yafang Shao

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=20170809164250.aza4csoc2jcwkvx7@hirez.programming.kicks-ass.net \
    --to=peterz@infradead.org \
    --cc=gregkh@linuxfoundation.org \
    --cc=jslaby@suse.com \
    --cc=laoar.shao@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@redhat.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

all inboxes | Powered by JetHome®