On Tue, Apr 27, 2021 at 11:36 AM Matthew Wilcox <willy@xxxxxxxxxxxxx> wrote: > > 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. I understand you. But I don't think our process needs this size. This size may be a bug in our code or somewhere, I don't know the RC for now. > [*] 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. > I just wanted to save some time when debugging. Regards
