All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Frank Ch. Eigler" <fche@redhat.com>
To: Valdis.Kletnieks@vt.edu
Cc: Andi Kleen <ak@suse.de>, Martin Peschke <mp3@de.ibm.com>,
	linux-kernel@vger.kernel.org, akpm@osdl.org, hch@infradead.org,
	arjan@infradead.org, James.Smart@emulex.com,
	James.Bottomley@steeleye.com, ltt-dev@shafik.org
Subject: Re: [RFC] [Patch 0/8] statistics infrastructure
Date: Wed, 17 May 2006 14:55:21 -0400	[thread overview]
Message-ID: <20060517185521.GM17707@redhat.com> (raw)
In-Reply-To: <200605171844.k4HIiPd1028516@turing-police.cc.vt.edu>

Hi -

On Wed, May 17, 2006 at 02:44:24PM -0400, Valdis.Kletnieks@vt.edu wrote:
> On Wed, 17 May 2006 14:28:08 EDT, "Frank Ch. Eigler" said:
> > I am not suggesting a single solution for all needs.  I wanted to
> > focus only one aspect: the marking of those points in the kernel where
> > something probeworthy occurs with hooks.  [...]
> 
> The problem is that the "common pool" ends up being a very wide swamp
> very fast.  [...]
> So under your plan, all 3 groups now use a "common pool" that includes
> slap, timing, latency, and other stuff - and nobody's using more than
> 1/3 of it, but paying the performance penalty for the 2/3 unused hooks....

It may not be clear, but by "pool", I mean some group of individually
activated hooks, doing little but calling some routine of
instrumentation with a few parameters.  Special-interest data like
timing, latency would be computed in the instrumentation code, not
necessarily at the hook site, so that part need incur no waste for
disinterested users.

Not-activated (dormant) hooks would indeed cost a little.  The
question is how much time/space cost is acceptable, in order to reap
the benefits of widely available probing.

- FChE

      reply	other threads:[~2006-05-17 18:55 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-05-16 17:44 [RFC] [Patch 0/8] statistics infrastructure Martin Peschke
2006-05-17 17:23 ` Frank Ch. Eigler
2006-05-17 18:05   ` Andi Kleen
2006-05-17 18:28     ` Frank Ch. Eigler
2006-05-17 18:44       ` Valdis.Kletnieks
2006-05-17 18:55         ` Frank Ch. Eigler [this message]

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=20060517185521.GM17707@redhat.com \
    --to=fche@redhat.com \
    --cc=James.Bottomley@steeleye.com \
    --cc=James.Smart@emulex.com \
    --cc=Valdis.Kletnieks@vt.edu \
    --cc=ak@suse.de \
    --cc=akpm@osdl.org \
    --cc=arjan@infradead.org \
    --cc=hch@infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=ltt-dev@shafik.org \
    --cc=mp3@de.ibm.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.