linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Michal Hocko <mhocko@kernel.org>
To: 段熊春 <duanxiongchun@bytedance.com>
Cc: dong <bauers@126.com>, Vladimir Davydov <vdavydov.dev@gmail.com>,
	Johannes Weiner <hannes@cmpxchg.org>,
	bugzilla-daemon@bugzilla.kernel.org, linux-mm@kvack.org,
	Andrew Morton <akpm@linux-foundation.org>
Subject: Re: [Bug 201699] New: kmemleak in memcg_create_kmem_cache
Date: Thu, 22 Nov 2018 08:32:48 +0100	[thread overview]
Message-ID: <20181122073248.GA18011@dhcp22.suse.cz> (raw)
In-Reply-To: <314D030F-2112-44E4-ABD3-A3A9B8597A3A@bytedance.com>

[Please do not top post]

On Thu 22-11-18 10:19:58, 段熊春 wrote:
> I had view the slab kmem_cache_alloc function,I think the virtual netdevice object will charged to memcg.
> Becuse the function slab_pre_alloc_hook will choose a kmem_cache, which belong to current task memcg.

Only for caches which opted in for kmem accounting SLAB_ACCOUNT or for
allocations with __GFP_ACCOUNT. Is this the case for the virtual
netdevice? I would check myself but I am not familiar with data
structures in this area.

> If  virtual netdevice object not destroy by another command, the virtual netdevice object will still charged to memcg, and the memcg will still in memory.

And that is why I've noted that charging objects which are not bound to
a user context and/or generally reclaimable under memory pressure are
not good candidates for kmem accounting.
-- 
Michal Hocko
SUSE Labs

  reply	other threads:[~2018-11-22  7:32 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <bug-201699-27@https.bugzilla.kernel.org/>
2018-11-15 21:06 ` [Bug 201699] New: kmemleak in memcg_create_kmem_cache Andrew Morton
2018-11-16  2:23   ` dong
2018-11-16  3:04     ` dong
2018-11-16  3:37       ` dong
2018-11-16 17:50   ` Vladimir Davydov
2018-11-18  0:44     ` dong
2018-11-19  8:30       ` Vladimir Davydov
2018-11-19 10:24         ` Michal Hocko
2018-11-19 11:56         ` dong
2018-11-21  8:46           ` dong
2018-11-21  8:56             ` Vladimir Davydov
2018-11-21  9:06               ` dong
2018-11-21  9:10             ` Michal Hocko
2018-11-21  9:22               ` dong
2018-11-21  9:36                 ` 段熊春
2018-11-21 16:27                   ` Michal Hocko
2018-11-22  2:19                     ` 段熊春
2018-11-22  7:32                       ` Michal Hocko [this message]
2018-11-22  2:56                     ` 段熊春
2018-11-22  7:34                       ` Michal Hocko
2018-11-22  8:21                         ` 段熊春
2018-11-23  6:54                         ` 段熊春
2018-11-21  8:52           ` Re: " Vladimir Davydov

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=20181122073248.GA18011@dhcp22.suse.cz \
    --to=mhocko@kernel.org \
    --cc=akpm@linux-foundation.org \
    --cc=bauers@126.com \
    --cc=bugzilla-daemon@bugzilla.kernel.org \
    --cc=duanxiongchun@bytedance.com \
    --cc=hannes@cmpxchg.org \
    --cc=linux-mm@kvack.org \
    --cc=vdavydov.dev@gmail.com \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).