From: Vladimir Davydov <vdavydov@virtuozzo.com>
To: Jesper Dangaard Brouer <brouer@redhat.com>
Cc: linux-mm@kvack.org, Joonsoo Kim <iamjoonsoo.kim@lge.com>,
Andrew Morton <akpm@linux-foundation.org>,
Christoph Lameter <cl@linux.com>
Subject: Re: [PATCH V2 2/2] slub: add missing kmem cgroup support to kmem_cache_free_bulk
Date: Sat, 7 Nov 2015 23:25:48 +0300 [thread overview]
Message-ID: <20151107202548.GO29259@esperanza> (raw)
In-Reply-To: <20151107175338.12a0368b@redhat.com>
On Sat, Nov 07, 2015 at 05:53:38PM +0100, Jesper Dangaard Brouer wrote:
> On Thu, 5 Nov 2015 19:25:14 +0300
> Vladimir Davydov <vdavydov@virtuozzo.com> wrote:
>
> > On Thu, Nov 05, 2015 at 04:38:06PM +0100, Jesper Dangaard Brouer wrote:
> > > Initial implementation missed support for kmem cgroup support
> > > in kmem_cache_free_bulk() call, add this.
> > >
> > > If CONFIG_MEMCG_KMEM is not enabled, the compiler should
> > > be smart enough to not add any asm code.
> > >
> > > Signed-off-by: Jesper Dangaard Brouer <brouer@redhat.com>
> > >
> > > ---
> > > V2: Fixes according to input from:
> > > Vladimir Davydov <vdavydov@virtuozzo.com>
> > > and Joonsoo Kim <iamjoonsoo.kim@lge.com>
> > >
> > > mm/slub.c | 3 +++
> > > 1 file changed, 3 insertions(+)
> > >
> > > diff --git a/mm/slub.c b/mm/slub.c
> > > index 8e9e9b2ee6f3..bc64514ad1bb 100644
> > > --- a/mm/slub.c
> > > +++ b/mm/slub.c
> > > @@ -2890,6 +2890,9 @@ void kmem_cache_free_bulk(struct kmem_cache *s, size_t size, void **p)
> > > do {
> > > struct detached_freelist df;
> > >
> > > + /* Support for memcg */
> > > + s = cache_from_obj(s, p[size - 1]);
> > > +
> >
> > AFAIU all objects in the array should come from the same cache (should
> > they?), so it should be enough to call this only once:
>
> Can we be sure all objects in the array come from same cache?
>
> Imagine my use case:
> 1. application send packet alloc a SKB (from a slab)
> 2. packet TX to NIC via DMA
> 3. TX DMA completion cleans up 256 packets and kmem free SKBs
>
> I don't know enough about mem cgroups... but I can imagine two
> applications belonging to different mem-cgroups sending packet out same
> NIC and later getting their SKB (pkt-metadata struct) free'ed during
> the same TX completion (TX softirq) cycle, as a bulk free.
Hmm, I thought that a bunch of objects allocated using
kmem_cache_alloc_bulk must be freed using kmem_cache_free_bulk. If it
does not hold, i.e. if one can allocate an array of objects one by one
using kmem_cache_alloc and then batch-free them using
kmem_cache_free_bulk, then my proposal is irrelevant.
>
> With my limited mem cgroups, it looks like memcg works on the slab-page
> level?
Yes, a memcg has its private copy of each global kmem cache it attempted
to use, which implies that all objects on the same slab-page must belong
to the same memcg.
> And what I'm doing in this code is to group object together
> belonging to the same slab-page.
Yeah, after inspecting build_detached_freelist more closely, I see your
patch is correct. Feel free to add
Reviewed-by: Vladimir Davydov <vdavydov@virtuozzo.com>
Thanks,
Vladimir
--
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-07 20:26 UTC|newest]
Thread overview: 33+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-11-05 15:37 [PATCH V2 0/2] SLUB bulk API interactions with kmem cgroup Jesper Dangaard Brouer
2015-11-05 15:37 ` [PATCH V2 1/2] slub: fix kmem cgroup bug in kmem_cache_alloc_bulk Jesper Dangaard Brouer
2015-11-05 16:18 ` Vladimir Davydov
2015-11-07 16:40 ` Jesper Dangaard Brouer
2015-11-05 15:38 ` [PATCH V2 2/2] slub: add missing kmem cgroup support to kmem_cache_free_bulk Jesper Dangaard Brouer
2015-11-05 16:25 ` Vladimir Davydov
2015-11-07 16:53 ` Jesper Dangaard Brouer
2015-11-07 20:25 ` Vladimir Davydov [this message]
2015-11-07 20:55 ` Christoph Lameter
2015-11-09 16:39 ` Jesper Dangaard Brouer
2015-11-09 18:38 ` Vladimir Davydov
2015-11-05 16:10 ` [PATCH V2 0/2] SLUB bulk API interactions with kmem cgroup Vladimir Davydov
2015-11-09 18:16 ` [PATCH V3 " Jesper Dangaard Brouer
2015-11-09 18:17 ` [PATCH V3 1/2] slub: fix kmem cgroup bug in kmem_cache_alloc_bulk Jesper Dangaard Brouer
2015-11-09 19:13 ` Vladimir Davydov
2015-11-09 20:25 ` Jesper Dangaard Brouer
2015-11-10 8:46 ` Vladimir Davydov
2015-11-10 15:55 ` Jesper Dangaard Brouer
2015-11-10 16:17 ` Christoph Lameter
2015-11-10 18:32 ` Vladimir Davydov
2015-11-11 15:28 ` Jesper Dangaard Brouer
2015-11-11 18:30 ` Jesper Dangaard Brouer
2015-11-11 18:56 ` Vladimir Davydov
2015-11-12 14:27 ` Jesper Dangaard Brouer
2015-11-09 22:04 ` Christoph Lameter
2015-11-10 8:30 ` Vladimir Davydov
2015-11-10 15:23 ` Christoph Lameter
2015-11-09 18:17 ` [PATCH V3 2/2] slub: add missing kmem cgroup support to kmem_cache_free_bulk Jesper Dangaard Brouer
2015-11-09 18:56 ` Vladimir Davydov
2015-11-13 10:57 ` [PATCH V4 0/2] SLUB bulk API interactions with kmem cgroup Jesper Dangaard Brouer
2015-11-13 10:57 ` [PATCH V4 1/2] slub: fix kmem cgroup bug in kmem_cache_alloc_bulk Jesper Dangaard Brouer
2015-11-14 11:04 ` Vladimir Davydov
2015-11-13 10:57 ` [PATCH V4 2/2] slub: add missing kmem cgroup support to kmem_cache_free_bulk Jesper Dangaard Brouer
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=20151107202548.GO29259@esperanza \
--to=vdavydov@virtuozzo.com \
--cc=akpm@linux-foundation.org \
--cc=brouer@redhat.com \
--cc=cl@linux.com \
--cc=iamjoonsoo.kim@lge.com \
--cc=linux-mm@kvack.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 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.