All of lore.kernel.org
 help / color / mirror / Atom feed
From: Roger Luethi <rl@hellgate.ch>
To: Robert Wisniewski <bob@watson.ibm.com>
Cc: zanussi@us.ibm.com, linux-kernel@vger.kernel.org,
	karim@opersys.com, richardj_moore@uk.ibm.com,
	michel.dagenais@polymtl.ca
Subject: Re: LTT user input
Date: Sat, 24 Jul 2004 01:45:02 +0200	[thread overview]
Message-ID: <20040723234502.GA12631@k3.hellgate.ch> (raw)
In-Reply-To: <16641.36290.751769.126111@k42.watson.ibm.com>

On Fri, 23 Jul 2004 18:40:26 -0400, Robert Wisniewski wrote:
>  > Looking for a common base was certainly easier before one tracing
>  > framework got merged. I don't claim to know if a common basic framework
>  > would be beneficial, but I am somewhat amazed that not more effort has
>  > gone into exploring this.
> 
> Argh.  I had up to this point been passively following this thread because
> a while ago, prior to dtrace and other such work I, Karim, and others
> invested quite of bit of effort and time responding to this group pointing
> out the benefits of performance monitoring via tracing and
> 
> IN FACT this was exactly one of the points I ardently made.  Having each
> subsystem set up their own monitoring was not only counter productive in
> terms of time and implementation effort, but prevented a unified view of
> performance from being achieved.  Nevertheless, it appears that some

This may be somewhat of a misunderstanding: You seem to be talking about
a unified framework for performance monitoring -- something I silently
assumed should be the case, while the discussion here was about various
forms of logging -- with performance monitoring being one of them.

So the question is (again, this is an issue that has been raised at the
kernel summit as well): Is there some overlap between those various
frameworks? Or do we really need completely separate frameworks for
logging time stamps (performance), auditing information, etc.?

> proclaimed by dtrace.  As Karim has pointed out in previous posts, though
> the technical concerns that were raised were addressed, it didn't seem to
> help as other nits would crop up appearing to imply that something else was
> happening.

My postings were motivated by my personal interest in better tracing
and monitoring facilities. However, I'm getting LKCD flashbacks when
reading your arguments. Which doesn't bode well.

> If indeed the remaining issue is whether there is a benefit to
> a performance monitoring infrastructure, then I wonder how you would
> interpret reactions to dtrace.

DTrace is not a performance monitoring infrastructure, so what's your
point? -- But let's assume for the sake of argument that LTT, dprobes
& Co.  provide something comparable to DTrace, and we just disagree on
what "performance monitoring" means: The chance of getting such a pile
of complexity into mainline are virtually zero (unless it's called ACPI
and required to boot some machines :-/).

So what you can push for inclusion is bound to be a subset, and the
question remains: What does such a subset, which is clearly nothing
like DTrace, offer?

Roger

  reply	other threads:[~2004-07-23 23:45 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-07-22 20:47 LTT user input zanussi
2004-07-23 10:01 ` Roger Luethi
2004-07-23 17:34   ` zanussi
2004-07-23 19:19     ` Roger Luethi
2004-07-23 20:44       ` zanussi
2004-07-23 22:06         ` Roger Luethi
2004-09-01 16:36           ` zanussi
2004-07-23 22:40       ` Robert Wisniewski
2004-07-23 23:45         ` Roger Luethi [this message]
2004-07-25 19:58           ` Karim Yaghmour
2004-07-25 21:10             ` Roger Luethi
2004-07-27 23:51             ` Tim Bird
2004-07-28  2:48 ` Todd Poynor

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=20040723234502.GA12631@k3.hellgate.ch \
    --to=rl@hellgate.ch \
    --cc=bob@watson.ibm.com \
    --cc=karim@opersys.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=michel.dagenais@polymtl.ca \
    --cc=richardj_moore@uk.ibm.com \
    --cc=zanussi@us.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.