linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Arnaldo Carvalho de Melo <acme@redhat.com>
To: Arjan van de Ven <arjan@infradead.org>
Cc: "Frank Ch. Eigler" <fche@redhat.com>,
	Arjan van de Ven <arjan@linux.intel.com>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	Linus Torvalds <torvalds@linux-foundation.org>,
	Ingo Molnar <mingo@elte.hu>,
	Andrew Morton <akpm@linux-foundation.org>
Subject: Re: [patch 2/3] Latencytop instrumentations part 1
Date: Fri, 18 Jan 2008 20:47:22 -0200	[thread overview]
Message-ID: <20080118224722.GB14456@ghostprotocols.net> (raw)
In-Reply-To: <20080118143334.28ba08ca@laptopd505.fenrus.org>

Em Fri, Jan 18, 2008 at 02:33:34PM -0800, Arjan van de Ven escreveu:
> On Fri, 18 Jan 2008 17:26:09 -0500
> fche@redhat.com (Frank Ch. Eigler) wrote:
> 
> > Arjan van de Ven <arjan@infradead.org> writes:
> > 
> > > This patch contains the first set of instrumentations for
> > > latencytop; each instrumentation needs to be evaluated for
> > > usefulness before this can go into mainline; posting here just to
> > > show how the infrastructure can be used
> > > [...]
> > 
> > Can you suggest of some reason why all this instrumentation could
> > not be in the form of standard markers (perhaps conditionally
> > compiled out if necessary)?
> > 
> 
> sure. Every instrumentation you see is of the nested kind (since the lowest level
> of nesting is already automatic via wchan).
> 
> If markers can provide me the following semantics, I'd be MORE than happy to use markers:
> 
> If the code path is like this
> 
> 
> set_latency_reason("Reading file");
>     ....
>     ....
>           set_latency_reason("Allocating memory");
>           kmalloc()  <--- blocks for 100 msec
>           restore_latency_reason()
>     ....
> restore_latency_reason();
> 
> via several layers of functions, the requirement is that the 100 msec is accounted 
> to "reading file" and not "Allocating memory". But if some other codepath hits the allocating memory function,
> without an outer "set_latency_reason", it should be accounted to "Allocating memory".
> 
> If markers can provide that semantics ... you sold me.

My limited understanding of markers is that you can attach something to
them that later work out any semantics you may want to associate with
them.

So I guess that as soon as the outermost marker is reached you can
just bump a counter and when the (several) inner markers are reached and
the counter is not zero you just bump it and go on with life, leaving
the latency measurement being done to the "owner" (outermost) marker.

Frank, am I talking bullshit?

- Arnaldo

  reply	other threads:[~2008-01-18 22:48 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-01-18 17:36 [Announce] Development release 0.1 of the LatencyTOP tool Arjan van de Ven
2008-01-18 17:39 ` [patch 1/3] LatencyTOP infrastructure patch Arjan van de Ven
2008-01-20 11:34   ` Helge Deller
2008-01-20 16:47   ` Dmitry Adamushko
2008-01-20 17:18     ` Dmitry Adamushko
2008-01-21  8:06   ` KOSAKI Motohiro
2008-01-21 16:16     ` Arjan van de Ven
2008-01-18 17:40 ` [patch 2/3] Latencytop instrumentations part 1 Arjan van de Ven
2008-01-18 22:26   ` Frank Ch. Eigler
2008-01-18 22:33     ` Arjan van de Ven
2008-01-18 22:47       ` Arnaldo Carvalho de Melo [this message]
2008-01-18 23:11       ` Frank Ch. Eigler
2008-01-18 23:20         ` Arjan van de Ven
2008-01-18 17:42 ` [patch 3/3] LatencyTOP instrumentations part 2 Arjan van de Ven
2008-01-18 18:27 ` [Announce] Development release 0.1 of the LatencyTOP tool Roberto Fichera
2008-01-18 18:35   ` Arjan van de Ven
2008-01-18 18:46     ` Roberto Fichera
2008-01-18 19:02 ` Zan Lynx
2008-01-19  5:07 ` Andi Kleen
2008-01-19  5:16   ` Arjan van de Ven
2008-01-19  5:27     ` Andi Kleen
2008-01-19  5:25       ` Arjan van de Ven
2008-01-19  5:33         ` Andi Kleen
2008-01-19  5:34           ` Arjan van de Ven
2008-01-19  6:08             ` Andi Kleen
2008-01-19  5:37           ` [Announce] Development release 0.1 of the LatencyTOP tool II Andi Kleen
2008-01-21  0:52 ` Development release 0.1 of the LatencyTOP tool KOSAKI Motohiro

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=20080118224722.GB14456@ghostprotocols.net \
    --to=acme@redhat.com \
    --cc=akpm@linux-foundation.org \
    --cc=arjan@infradead.org \
    --cc=arjan@linux.intel.com \
    --cc=fche@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@elte.hu \
    --cc=torvalds@linux-foundation.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;
as well as URLs for NNTP newsgroup(s).