public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Andi Kleen <andi@firstfloor.org>
To: Alex Neronskiy <zakmagnus@chromium.org>
Cc: linux-kernel@vger.kernel.org, peterz@infradead.org,
	Ingo Molnar <mingo@elte.hu>, Don Zickus <dzickus@redhat.com>,
	Mandeep Singh Baines <msb@chromium.org>,
	Alex Neronskiy <zakmagnus@chromium.com>
Subject: Re: [PATCH v6 2/2] Output stall data in debugfs
Date: Thu, 11 Aug 2011 11:48:26 -0700	[thread overview]
Message-ID: <m2bovvn5s5.fsf@firstfloor.org> (raw)
In-Reply-To: <1312999364-21104-2-git-send-email-zakmagnus@chromium.org> (Alex Neronskiy's message of "Wed, 10 Aug 2011 11:02:44 -0700")

Alex Neronskiy <zakmagnus@chromium.org> writes:

> From: Alex Neronskiy <zakmagnus@chromium.com>
>
> Instead of using the log, use debugfs for output of both stall
> lengths and stack traces. Printing to the log can result in
> watchdog touches, 

Why? Because of printk being slow or something else?

The first could be probably workarounded, especially if you
already have "two buffers"

> distorting the very events being measured.
> Additionally, the information will not distract from lockups
> when users view the log.
>
> A two-buffer system is used to ensure that the trace information
> can always be recorded without contention.

This implies that kernel bug reports will often not contain the 
back trace, right? Seems like a bad thing to me because it will
make bug reports worse.

-Andi

-- 
ak@linux.intel.com -- Speaking for myself only

  reply	other threads:[~2011-08-11 18:48 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-08-10 18:02 [PATCH v6 1/2] Track hard and soft "short lockups" or "stalls." Alex Neronskiy
2011-08-10 18:02 ` [PATCH v6 2/2] Output stall data in debugfs Alex Neronskiy
2011-08-11 18:48   ` Andi Kleen [this message]
2011-08-11 19:04     ` Don Zickus
2011-08-11 21:05       ` Andi Kleen
2011-08-11 19:13   ` Peter Zijlstra
2011-08-11 19:35   ` Peter Zijlstra
2011-08-11 20:10     ` Alex Neronskiy
2011-08-11 20:23       ` Peter Zijlstra
2011-08-11 20:31         ` Alex Neronskiy
2011-08-11 21:17           ` Peter Zijlstra
2011-08-11 22:02             ` Alex Neronskiy
2011-08-11 23:00             ` Mandeep Singh Baines
2011-08-12 12:14               ` Peter Zijlstra
2011-08-16 19:32                 ` Mandeep Singh Baines
2011-08-12  9:06     ` Ingo Molnar
2011-08-12 19:46       ` Alex Neronskiy
2011-08-11 19:43   ` Peter Zijlstra
2011-08-11 19:51     ` Alex Neronskiy
2011-08-11 19:57       ` Peter Zijlstra
2011-08-11 19:09 ` [PATCH v6 1/2] Track hard and soft "short lockups" or "stalls." Peter Zijlstra

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=m2bovvn5s5.fsf@firstfloor.org \
    --to=andi@firstfloor.org \
    --cc=dzickus@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@elte.hu \
    --cc=msb@chromium.org \
    --cc=peterz@infradead.org \
    --cc=zakmagnus@chromium.com \
    --cc=zakmagnus@chromium.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox