From: Vladimir Davydov <vdavydov@virtuozzo.com>
To: Michal Hocko <mhocko@kernel.org>
Cc: Andrew Morton <akpm@linux-foundation.org>,
Johannes Weiner <hannes@cmpxchg.org>, Tejun Heo <tj@kernel.org>,
Greg Thelen <gthelen@google.com>,
Christoph Lameter <cl@linux.com>,
Pekka Enberg <penberg@kernel.org>,
David Rientjes <rientjes@google.com>,
Joonsoo Kim <iamjoonsoo.kim@lge.com>,
linux-mm@kvack.org, cgroups@vger.kernel.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH v2 4/6] slab: add SLAB_ACCOUNT flag
Date: Sat, 14 Nov 2015 14:29:24 +0300 [thread overview]
Message-ID: <20151114112924.GF31308@esperanza> (raw)
In-Reply-To: <20151112161741.GN1174@dhcp22.suse.cz>
On Thu, Nov 12, 2015 at 05:17:41PM +0100, Michal Hocko wrote:
> On Tue 10-11-15 21:34:05, Vladimir Davydov wrote:
> > Currently, if we want to account all objects of a particular kmem cache,
> > we have to pass __GFP_ACCOUNT to each kmem_cache_alloc call, which is
> > inconvenient. This patch introduces SLAB_ACCOUNT flag which if passed to
> > kmem_cache_create will force accounting for every allocation from this
> > cache even if __GFP_ACCOUNT is not passed.
>
> Yes this is much better and less error prone for dedicated caches.
>
> > This patch does not make any of the existing caches use this flag - it
> > will be done later in the series.
> >
> > Note, a cache with SLAB_ACCOUNT cannot be merged with a cache w/o
> > SLAB_ACCOUNT, i.e. using this flag will probably reduce the number of
> > merged slabs even if kmem accounting is not used (only compiled in).
>
> I would expect some reasoning why this is the case. Why cannot caches of
> the same memcg be merged? I remember you have mentioned something in the
> previous discussion with Tejun but it should be in the changelog as well
> IMO.
Here goes an extended version of the last paragraph, hope it makes
everything clear:
"""
Note, a cache with SLAB_ACCOUNT cannot be merged with a cache w/o
SLAB_ACCOUNT, because merged caches share the same kmem_cache struct and
hence cannot have different sets of SLAB_* flags. Thus using this flag
will probably reduce the number of merged slabs even if kmem accounting
is not used (only compiled in).
"""
Andrew, could you please update the commit message?
>
> > Suggested-by: Tejun Heo <tj@kernel.org>
> > Signed-off-by: Vladimir Davydov <vdavydov@virtuozzo.com>
>
> I am not sufficiently qualified to judge the slab implementation
> specifics but for the overal approach
>
> Acked-by: Michal Hocko <mhocko@suse.com>
Thanks!
--
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>
next prev parent reply other threads:[~2015-11-14 11:29 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-11-10 18:34 [PATCH v2 0/6] memcg/kmem: switch to white list policy Vladimir Davydov
2015-11-10 18:34 ` [PATCH v2 1/6] Revert "kernfs: do not account ino_ida allocations to memcg" Vladimir Davydov
2015-11-19 18:56 ` Johannes Weiner
2015-11-10 18:34 ` [PATCH v2 2/6] Revert "gfp: add __GFP_NOACCOUNT" Vladimir Davydov
2015-11-19 18:59 ` Johannes Weiner
2015-11-10 18:34 ` [PATCH v2 3/6] memcg: only account kmem allocations marked as __GFP_ACCOUNT Vladimir Davydov
2015-11-12 16:04 ` Michal Hocko
2015-11-19 19:00 ` Johannes Weiner
2015-11-10 18:34 ` [PATCH v2 4/6] slab: add SLAB_ACCOUNT flag Vladimir Davydov
2015-11-10 18:38 ` Tejun Heo
2015-11-10 18:54 ` Vladimir Davydov
2015-11-11 15:54 ` Tejun Heo
2015-11-11 16:07 ` Vladimir Davydov
2015-11-11 16:19 ` Tejun Heo
2015-11-12 16:17 ` Michal Hocko
2015-11-14 11:29 ` Vladimir Davydov [this message]
2015-11-19 19:01 ` Johannes Weiner
2015-11-10 18:34 ` [PATCH v2 5/6] vmalloc: allow to account vmalloc to memcg Vladimir Davydov
2015-11-19 19:04 ` Johannes Weiner
2015-11-10 18:34 ` [PATCH v2 6/6] Account certain kmem allocations " Vladimir Davydov
2015-11-12 16:50 ` Michal Hocko
2015-11-19 19:12 ` 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=20151114112924.GF31308@esperanza \
--to=vdavydov@virtuozzo.com \
--cc=akpm@linux-foundation.org \
--cc=cgroups@vger.kernel.org \
--cc=cl@linux.com \
--cc=gthelen@google.com \
--cc=hannes@cmpxchg.org \
--cc=iamjoonsoo.kim@lge.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mhocko@kernel.org \
--cc=penberg@kernel.org \
--cc=rientjes@google.com \
--cc=tj@kernel.org \
/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