[lkml]   [2009]   [Aug]   [8]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [PATCH 1/4] tracing, page-allocator: Add trace events for page allocation and page freeing
    >> > In the NUMA case, this will be true but addressing it involves passing down
    >> > an additional argument in the non-tracing case which I wanted to avoid.
    >> > As the stacktrace option is available to ftrace, I think I'll drop call_site
    >> > altogether as anyone who really needs that information has options.
    >> Insted, can we move this tracepoint to alloc_pages_current(), alloc_pages_node() et al ?
    >> On page tracking case, call_site information is one of most frequently used one.
    >> if we need multiple trace combination, it become hard to use and reduce usefulness a bit.
    > Ok, lets think about that. The potential points that would need
    > annotation are
    >        o alloc_pages_current
    >        o alloc_page_vma
    >        o alloc_pages_node
    >        o alloc_pages_exact_node
    > The inlined functions that call those and should preserve the call_site
    > are
    >        o alloc_pages
    > The slightly lower functions they call are as follows. These cannot
    > trigger a tracepoint event because it would look like a duplicate.
    >        o __alloc_pages_nodemask
    >                - called by __alloc_pages
    >        o __alloc_pages
    >                - called by alloc_page_interleave() but event logged
    >                - called by alloc_pages_node but event logged
    >                - called by alloc_pages_exact_node but event logged
    > The more problematic ones are
    >        o __get_free_pages
    >        o get_zeroed_page
    >        o alloc_pages_exact
    > The are all real functions that call down to functions that would log
    > events already based on your suggestion - alloc_pages_current() in
    > particularly.
    > Looking at it, it would appear the page allocator API would need a fair
    > amount of reschuffling to preserve call_site and not duplicate events or
    > else to pass call_site down through the API even in the non-tracing case.
    > Minimally, that makes it a standalone patch but it would also need a good
    > explanation as to why capturing the stack trace on the event is not enough
    > to track the page for things like catching memory leaks.

    I agree this is need to some cleanup.
    I think I can do that and I can agree your.
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    More majordomo info at
    Please read the FAQ at

     \ /
      Last update: 2009-08-08 07:55    [W:0.024 / U:81.012 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site