lkml.org 
[lkml]   [2021]   [May]   [3]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    SubjectRe: [PATCH] mm: append __GFP_COMP flag for trace_malloc
    From
    Date
    On 4/28/21 5:05 AM, Xiongwei Song wrote:
    > On Tue, Apr 27, 2021 at 7:26 PM Matthew Wilcox <willy@infradead.org> wrote:
    >>
    >> On Tue, Apr 27, 2021 at 01:30:48PM +0800, Xiongwei Song wrote:
    >> > Hi Mattew,
    >> >
    >> > One more thing I should explain, the kmalloc_order() appends the
    >> > __GFP_COMP flags,
    >> > not by the caller.
    >> >
    >> > void *kmalloc_order(size_t size, gfp_t flags, unsigned int order)
    >> > {
    >> > ...........................................................
    >> >
    >> > flags |= __GFP_COMP;
    >> > page = alloc_pages(flags, order);
    >> > ...........................................................
    >> > return ret;
    >> > }
    >> > EXPORT_SYMBOL(kmalloc_order);
    >> >
    >> > #ifdef CONFIG_TRACING
    >> > void *kmalloc_order_trace(size_t size, gfp_t flags, unsigned int order)
    >> > {
    >> > void *ret = kmalloc_order(size, flags, order);
    >> > trace_kmalloc(_RET_IP_, ret, size, PAGE_SIZE << order, flags);
    >> > return ret;
    >> > }
    >> > EXPORT_SYMBOL(kmalloc_order_trace);
    >> > #endif
    >>
    >> Yes, I understood that. What I don't understand is why appending the
    >> __GFP_COMP to the trace would have been less confusing for you.
    >>
    >> Suppose I have some code which calls:
    >>
    >> kmalloc(10 * 1024, GFP_ATOMIC|__GFP_NOWARN|__GFP_NOMEMALLOC);
    >>
    >> and I see in my logs
    >>
    >> 0.08% call_site=ffffffff851d0cb0 ptr=0xffff8c04a4ca0000 bytes_req=10176 bytes_alloc=16384 gfp_flags=GFP_ATOMIC|__GFP_NOWARN|__GFP_NOMEMALLOC|__GFP_COMP
    >>
    >> That seems to me _more_ confusing because I would wonder "Where did that
    >> __GFP_COMP come from?"
    >
    > Thank you for the comments. But I disagree.

    FTR, I agree with Matthew. This is a tracepoint for kmalloc() so I would expect
    to see what flags were passed to kmalloc().
    If I wanted to see how the flags translated to page allocator's flags, I would
    have used a page allocator's tracepoint which would show me that.

    > When I use trace, I hope I can get the precise data rather than something
    > changed that I don't know , then I can get the correct conclusion or
    > direction on my issue.

    It's precise from the point of the caller.

    > Here my question is what the trace events are for if they don't provide the
    > real situation? I think that's not graceful and friendly.
    >
    > From my perspective, it'd be better to know my flags changed before checking
    > code lines one by one. In other words, I need a warning to reminder me on this,
    > then I can know quickly my process might do some incorrect things.

    Your process should not care about __GFP_COMP if you use properly
    kmalloc()+kfree(). Once you start caring about __GFP_COMP, you should be using
    page allocator's API, not kmalloc().

    > Regards,
    > Xiongwei
    >

    \
     
     \ /
      Last update: 2021-05-03 14:35    [W:5.811 / U:0.136 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site