Messages in this thread | | | Date | Fri, 6 Mar 2009 18:46:29 +0100 | From | Ingo Molnar <> | Subject | Re: [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
| |