Re: [patch 2/3] Latencytop instrumentations part 1

From: Arnaldo Carvalho de Melo
Date: Fri Jan 18 2008 - 17:48:10 EST


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@xxxxxxxxxx (Frank Ch. Eigler) wrote:
>
> > Arjan van de Ven <arjan@xxxxxxxxxxxxx> 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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/