> 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.
