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

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

Post by KOSAKI Mot » Sun, 09 Aug 2009 15:00:27


>> > In the NUMA case, this will be true but addressing it involves passing down
> alloc_page>vma
> alloc_pag>s_node
> alloc_pages_>xa>t_node
>
> The inlined functions that call those and should preserve the>call_s>te> > are
>
> gt; a>loc_pages
>
> The slightly lower functions they call are as follows.>These cannot
> trigger a tracepoint event because it would look like>a >uplicate.
>
> __allo>_pages_nodemask
> >called by __alloc_page>
> __alloc_pages
> called by alloc>page_interleave() but event logged
> >alled by alloc_pages_node but event logged
> gt; c>lled by alloc_pages_exact_node b>t >vent logged
>
> The mor> problematic ones are
>> > __get_free_pag>s >> get_zeroed_page
> alloc_pages_exact
>
> The are a>l real functions that call down to functions that would log
> events>already based on>yo>r suggestion - alloc_pages_current() in
> particularly.
>
> Looking at >t, it would appear the page allocator API would need a fair
> amount of re>chuffling to preserve call_site and not duplicate events or
> else to pass >all_site down through the API even in the non-tracing case.
> Minimally, th>t 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 XXXX@XXXXX.COM
More majordomo info at http://www.yqcomputer.com/
Please read the FAQ at http://www.yqcomputer.com/