From: Johannes Weiner <hannes@cmpxchg.org>
To: Vladimir Davydov <vdavydov@virtuozzo.com>
Cc: Andrew Morton <akpm@linux-foundation.org>,
Michal Hocko <mhocko@kernel.org>,
linux-mm@kvack.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH 4/5] radix-tree: account radix_tree_node to memory cgroup
Date: Mon, 8 Feb 2016 01:01:36 -0500 [thread overview]
Message-ID: <20160208060136.GD22202@cmpxchg.org> (raw)
In-Reply-To: <886d4b42a50c77c45ece9c0e685fc25f8f7643c9.1454864628.git.vdavydov@virtuozzo.com>
On Sun, Feb 07, 2016 at 08:27:34PM +0300, Vladimir Davydov wrote:
> Allocation of radix_tree_node objects can be easily triggered from
> userspace, so we should account them to memory cgroup. Besides, we need
> them accounted for making shadow node shrinker per memcg (see
> mm/workingset.c).
>
> A tricky thing about accounting radix_tree_node objects is that they are
> mostly allocated through radix_tree_preload(), so we can't just set
> SLAB_ACCOUNT for radix_tree_node_cachep - that would likely result in a
> lot of unrelated cgroups using objects from each other's caches.
>
> One way to overcome this would be making radix tree preloads per memcg,
> but that would probably look cumbersome and overcomplicated.
>
> Instead, we make radix_tree_node_alloc() first try to allocate from the
> cache with __GFP_ACCOUNT, no matter if the caller has preloaded or not,
> and only if it fails fall back on using per cpu preloads. This should
> make most allocations accounted.
>
> Signed-off-by: Vladimir Davydov <vdavydov@virtuozzo.com>
Acked-by: Johannes Weiner <hannes@cmpxchg.org>
I'm not too stoked about the extra slab call. But the preload call
allocates nodes for the worst-case insertion, so you are absolutely
right that charging there would not make sense for cgroup ownership.
And I can't think of anything better to do here.
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
WARNING: multiple messages have this Message-ID (diff)
From: Johannes Weiner <hannes@cmpxchg.org>
To: Vladimir Davydov <vdavydov@virtuozzo.com>
Cc: Andrew Morton <akpm@linux-foundation.org>,
Michal Hocko <mhocko@kernel.org>,
linux-mm@kvack.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH 4/5] radix-tree: account radix_tree_node to memory cgroup
Date: Mon, 8 Feb 2016 01:01:36 -0500 [thread overview]
Message-ID: <20160208060136.GD22202@cmpxchg.org> (raw)
In-Reply-To: <886d4b42a50c77c45ece9c0e685fc25f8f7643c9.1454864628.git.vdavydov@virtuozzo.com>
On Sun, Feb 07, 2016 at 08:27:34PM +0300, Vladimir Davydov wrote:
> Allocation of radix_tree_node objects can be easily triggered from
> userspace, so we should account them to memory cgroup. Besides, we need
> them accounted for making shadow node shrinker per memcg (see
> mm/workingset.c).
>
> A tricky thing about accounting radix_tree_node objects is that they are
> mostly allocated through radix_tree_preload(), so we can't just set
> SLAB_ACCOUNT for radix_tree_node_cachep - that would likely result in a
> lot of unrelated cgroups using objects from each other's caches.
>
> One way to overcome this would be making radix tree preloads per memcg,
> but that would probably look cumbersome and overcomplicated.
>
> Instead, we make radix_tree_node_alloc() first try to allocate from the
> cache with __GFP_ACCOUNT, no matter if the caller has preloaded or not,
> and only if it fails fall back on using per cpu preloads. This should
> make most allocations accounted.
>
> Signed-off-by: Vladimir Davydov <vdavydov@virtuozzo.com>
Acked-by: Johannes Weiner <hannes@cmpxchg.org>
I'm not too stoked about the extra slab call. But the preload call
allocates nodes for the worst-case insertion, so you are absolutely
right that charging there would not make sense for cgroup ownership.
And I can't think of anything better to do here.
next prev parent reply other threads:[~2016-02-08 6:01 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-02-07 17:27 [PATCH 0/5] mm: workingset: make shadow node shrinker memcg aware Vladimir Davydov
2016-02-07 17:27 ` Vladimir Davydov
2016-02-07 17:27 ` [PATCH 1/5] mm: memcontrol: enable kmem accounting for all cgroups in the legacy hierarchy Vladimir Davydov
2016-02-07 17:27 ` Vladimir Davydov
2016-02-08 5:46 ` Johannes Weiner
2016-02-08 5:46 ` Johannes Weiner
2016-02-07 17:27 ` [PATCH 2/5] mm: vmscan: pass root_mem_cgroup instead of NULL to memcg aware shrinker Vladimir Davydov
2016-02-07 17:27 ` Vladimir Davydov
2016-02-08 5:47 ` Johannes Weiner
2016-02-08 5:47 ` Johannes Weiner
2016-02-07 17:27 ` [PATCH 3/5] mm: memcontrol: zap memcg_kmem_online helper Vladimir Davydov
2016-02-07 17:27 ` Vladimir Davydov
2016-02-08 5:48 ` Johannes Weiner
2016-02-08 5:48 ` Johannes Weiner
2016-02-07 17:27 ` [PATCH 4/5] radix-tree: account radix_tree_node to memory cgroup Vladimir Davydov
2016-02-07 17:27 ` Vladimir Davydov
2016-02-08 6:01 ` Johannes Weiner [this message]
2016-02-08 6:01 ` Johannes Weiner
2016-02-07 17:27 ` [PATCH 5/5] mm: workingset: make shadow node shrinker memcg aware Vladimir Davydov
2016-02-07 17:27 ` Vladimir Davydov
2016-02-08 6:23 ` Johannes Weiner
2016-02-08 6:23 ` Johannes Weiner
2016-02-08 14:28 ` Vladimir Davydov
2016-02-08 14:28 ` Vladimir Davydov
2016-02-08 20:43 ` Johannes Weiner
2016-02-08 20:43 ` Johannes Weiner
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=20160208060136.GD22202@cmpxchg.org \
--to=hannes@cmpxchg.org \
--cc=akpm@linux-foundation.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mhocko@kernel.org \
--cc=vdavydov@virtuozzo.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 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.