mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: David Mosberger <davidm@napali.hpl.hp.com>
To: William Lee Irwin III <wli@holomorphy.com>
Cc: akpm@osdl.org, linux-kernel@vger.kernel.org
Subject: Re: [0.5/2] scheduler caller profiling
Date: Mon, 3 May 2004 11:51:35 -0700	[thread overview]
Message-ID: <16534.38071.912606.952360@napali.hpl.hp.com> (raw)
In-Reply-To: <20040503022346.GG1397@holomorphy.com>


  Bill> On Sun, May 02, 2004 at 07:17:09PM -0700, William Lee Irwin
  Bill> III wrote:
  >> The thundering herd issue in waitqueue hashing has been seen in
  >> practice. In order to preserve the space footprint reduction
  >> while improving performance, I wrote "filtered wakeups", which
  >> discriminate between waiters based on a key.

  Bill> This patch was used to collect the data on the offending
  Bill> callers into the scheduler. It creates a profile buffer
  Bill> completely analogous to its handling to /proc/profile, but
  Bill> registers profile ticks at calls to the various scheduler
  Bill> entry points instead of during timer ticks and rearranges
  Bill> scheduler code for this to be accounted properly. It does not
  Bill> report meaningful statistics in the presence of
  Bill> CONFIG_PREEMPT.

  Bill> Posting this patch is in order to disclose how I obtained the
  Bill> scheduling statistics reported in the first post. This patch
  Bill> is not intended for inclusion.

Note that on ia64, you can use q-syscollect/q-view to collect
call-counts statistically (with zero intrusion to the monitored
program, so it's safe for the kernel).  While the call-graph/counts
won't be perfectly accurate, this has proven to work extremely well in
practice.  In fact, it would be nice if other arches could support the
same.  All you really need for this to work is the ability to count N
call (or return) instructions and record the source and destination
address of the N-th call somewhere (registers or memory).  I looked at
the P4 performance-monitor briefly but I couldn't quite figure out
whether it supports the required functionality (it seemed like it
could only record _all_ branches, which would be a problem).  If a
P4-expert is interested in pursuing this, let me know.  I'd be happy
to help/advise with some of the more subtle issues that need to be
address to get this to work correctly.

	--david

  parent reply	other threads:[~2004-05-03 18:52 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-05-03  2:17 [0/2] filtered wakeups William Lee Irwin III
2004-05-03  2:23 ` [0.5/2] scheduler caller profiling William Lee Irwin III
2004-05-03  2:29   ` William Lee Irwin III
2004-05-03  2:32     ` [2/2] filtered buffer_head wakeups William Lee Irwin III
2004-05-03 18:51   ` David Mosberger [this message]
2004-05-03  2:46 ` [0/2] filtered wakeups William Lee Irwin III
2004-05-03 12:18 [0.5/2] scheduler caller profiling Oleg Nesterov

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=16534.38071.912606.952360@napali.hpl.hp.com \
    --to=davidm@napali.hpl.hp.com \
    --cc=akpm@osdl.org \
    --cc=davidm@hpl.hp.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=wli@holomorphy.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®