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

    * Peter Zijlstra <> 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?


     \ /
      Last update: 2009-03-06 18:51    [W:0.034 / U:1.596 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site