On Tue, Apr 27, 2021 at 11:29:32AM +0800, Xiongwei Song wrote: > On Tue, Apr 27, 2021 at 10:54 AM Matthew Wilcox <willy@xxxxxxxxxxxxx> wrote: > > > > On Tue, Apr 27, 2021 at 10:43:20AM +0800, Xiongwei Song wrote: > > > From: Xiongwei Song <sxwjean@xxxxxxxxx> > > > > > > When calling kmalloc_order, the flags should include __GFP_COMP here, > > > so that trace_malloc can trace the precise flags. > > > > I suppose that depends on your point of view. > Correct. > > Should we report the > > flags used by the caller, or the flags that we used to allocate memory? > > And why does it matter? > When I capture kmem:kmalloc events on my env with perf: > (perf record -p my_pid -e kmem:kmalloc) > I got the result below: > 0.08% call_site=ffffffff851d0cb0 ptr=0xffff8c04a4ca0000 > bytes_req=10176 bytes_alloc=16384 > gfp_flags=GFP_ATOMIC|__GFP_NOWARN|__GFP_NOMEMALLOC Hmm ... if you have a lot of allocations about this size, that would argue in favour of adding a kmem_cache of 10880 [*] bytes. That way, we'd get 3 allocations per 32kB instead of 2. [*] 32768 / 3, rounded down to a 64 byte cacheline But I don't understand why this confused you. Your caller at ffffffff851d0cb0 didn't specify __GFP_COMP. I'd be more confused if this did report __GFP_COMP.
