lkml.org 
[lkml]   [2009]   [Aug]   [5]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH 4/4] tracing, page-allocator: Add a postprocessing script for page-allocator-related ftrace events

* Andrew Morton <akpm@linux-foundation.org> wrote:

> On Tue, 4 Aug 2009 22:35:26 +0200
> Ingo Molnar <mingo@elte.hu> wrote:
>
> > Did you never want to see whether firefox is leaking [any sort of]
> > memory, and if yes, on what callsites? Try something like on an
> > already running firefox context:
> >
> > perf stat -e kmem:mm_page_alloc \
> > -e kmem:mm_pagevec_free \
> > -e kmem:mm_page_free_direct \
> > -p $(pidof firefox-bin) sleep 10
> >
> > ... and "perf record" for the specific callsites.
>
> OK, that would be useful. What does the output look like?

I suspect Mel's output is an even better example.

> In what way is it superior to existing ways of finding leaks?

It's barely useful in this form - i just demoed the capability. perf
stat is not a 'leak finding' special-purpose tool, but a generic
tool that i used for this purpose as well, on an ad-hoc basis.

Tools that can be used in unexpected but still useful ways tend to
be the best ones.

The kind of information these tracepoints expose, combined with the
sampling and analysis features of perfcounters is the most
high-quality information one can get about the page allocator IMO.

This is my general point: instead of wasting time and effort
extending derived information, why not expose the core information?
When the tracepoints are off there is essentially no overhead.
(which is an added benefit - all the /proc/vmstat bits are collected
unconditionally and then have to be summed up from all cpus when
read out.)

> > this perf stuff is immensely flexible and a very unixish
> > abstraction. The perf.data contains timestamped trace entries of
> > page allocations and freeing done.
> >
> > [...]
> > > It would be nice to at least partially remove the vmstat/meminfo
> > > infrastructure but I don't think we can do that?
> >
> > at least meminfo is an ABI for sure - vmstat too really.
> >
> > But we can stop adding new fields into obsolete, inflexible and
> > clearly deficient interfaces, and we can standardize new
> > instrumentation to use modern instrumentation facilities - i.e.
> > tracepoints and perfcounters.
>
> That's bad. Is there really no way in which we can consolidate
> _any_ of that infrastructure? We just pile in new stuff alongside
> the old?
>
> The worst part is needing two unrelated sets of userspace tools to
> access basically-identical things.

We certainly should expose the full set of information to the new
facility, so that it's self-sufficient and does not have to go
digging in /proc for odd bits here and there (in various ad-hoc
formats).

Above i'm arguing that since the old bits are an ABI, they should be
kept but not extended.

btw., this is why i was resisting ad-hoc hacks like kpageflags.
Those special-purpose instrumentation ABIs are hard to get rid of,
and they come nowhere close to the utility of the real thing.

Ingo


\
 
 \ /
  Last update: 2009-08-05 09:57    [W:0.066 / U:0.052 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site