Re: [PATCH 1/4] tracing, page-allocator: Add trace events for page allocation and page freeing

[KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>]

>> > 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, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>