lkml.org 
[lkml]   [2009]   [Mar]   [6]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [Patch] mm tracepoints

* Peter Zijlstra <peterz@infradead.org> wrote:

> On Fri, 2009-03-06 at 18:10 +0100, Ingo Molnar wrote:
> > Looks pretty good and useful to me. I've Cc:-ed more mm folks,
> > it would be nice to hear their opinion about these tracepoints.
> >
> > Andrew, Nick, Peter, what do you think?
>
> Bit sad we use the struct mm_struct * as mm identifier (little
> %lx vs %p confusion there too), but I suppose there simply
> isn't anything better.

the other option would be to trace the pgd physical pfn value.
The physical address of the pagetable is a pretty fundamental
thing so that abstraction is unlikely to change.

> Exposing kernel pointers like that might upset some of the
> security folks, not sure if I care though.

it's admin-only.

> I'm missing the fault_filemap_read counterpart of
> fault_anon_pgin.
>
> Once you have anon/filemap symmetric, you might consider
> folding these and doing the anon argument thing you do
> elsewhere.
>
> Initially I was thinking we lacked the kswapd vs direct
> reclaim information on the pgout data, but since we log the
> pid:comm for each event...
>
> Which brings us to mm_pdflush_*, we can already see its
> pdflush from pid:comm, then again, it fits the naming style.
> Same for mm_directreclaim*() - we already know its direct,
> since its not kswapd doing it.
>
> Finally, we have page_free, but not page_alloc? Oh, it is
> there, just not in the obvious place.
>
> Things missing, we trace unmap, but not mmap, mprotect, mlock?
>
> pagelock perhaps?

yeah, pagelock would be nice. In a similar way to lockdep
tracing. Maybe it should be part of lock tracing?

Ingo


\
 
 \ /
  Last update: 2009-03-06 18:51    [from the cache]
©2003-2011 Jasper Spaans