All of lore.kernel.org
 help / color / mirror / Atom feed
From: Matthew Wilcox <willy@infradead.org>
To: Xiongwei Song <sxwjean@gmail.com>
Cc: Xiongwei Song <sxwjean@me.com>,
	cl@linux.com, penberg@kernel.org, rientjes@google.com,
	iamjoonsoo.kim@lge.com, akpm@linux-foundation.org,
	vbabka@suse.cz, linux-mm@kvack.org,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] mm: append __GFP_COMP flag for trace_malloc
Date: Tue, 27 Apr 2021 04:36:32 +0100	[thread overview]
Message-ID: <20210427033632.GW235567@casper.infradead.org> (raw)
In-Reply-To: <CAEVVKH_wZJvNAgFEF1OxThxN3AC4mopZ+Pu2GC0Hn_-2JOfC5Q@mail.gmail.com>

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@infradead.org> wrote:
> >
> > On Tue, Apr 27, 2021 at 10:43:20AM +0800, Xiongwei Song wrote:
> > > From: Xiongwei Song <sxwjean@gmail.com>
> > >
> > > 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.


  reply	other threads:[~2021-04-27  3:37 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-04-27  2:43 [PATCH] mm: append __GFP_COMP flag for trace_malloc Xiongwei Song
2021-04-27  2:53 ` Matthew Wilcox
2021-04-27  3:29   ` Xiongwei Song
2021-04-27  3:29     ` Xiongwei Song
2021-04-27  3:36     ` Matthew Wilcox [this message]
2021-04-27  4:11       ` Xiongwei Song
2021-04-27  4:11         ` Xiongwei Song
2021-04-27  5:30         ` Xiongwei Song
2021-04-27  5:30           ` Xiongwei Song
2021-04-27 11:25           ` Matthew Wilcox
2021-04-28  3:05             ` Xiongwei Song
2021-04-28  3:05               ` Xiongwei Song
2021-05-03 12:35               ` Vlastimil Babka
2021-05-07  5:41                 ` Xiongwei Song
2021-05-07  5:41                   ` Xiongwei Song

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20210427033632.GW235567@casper.infradead.org \
    --to=willy@infradead.org \
    --cc=akpm@linux-foundation.org \
    --cc=cl@linux.com \
    --cc=iamjoonsoo.kim@lge.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=penberg@kernel.org \
    --cc=rientjes@google.com \
    --cc=sxwjean@gmail.com \
    --cc=sxwjean@me.com \
    --cc=vbabka@suse.cz \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body. 
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.