linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Christoph Lameter <cl@linux.com>
To: Vladimir Davydov <vdavydov@parallels.com>
Cc: hannes@cmpxchg.org, mhocko@suse.cz, akpm@linux-foundation.org,
	linux-kernel@vger.kernel.org, linux-mm@kvack.org
Subject: Re: [PATCH RFC 3/3] slub: reparent memcg caches' slabs on memcg offline
Date: Fri, 16 May 2014 10:03:22 -0500 (CDT)	[thread overview]
Message-ID: <alpine.DEB.2.10.1405160957100.32249@gentwo.org> (raw)
In-Reply-To: <20140516132234.GF32113@esperanza>

On Fri, 16 May 2014, Vladimir Davydov wrote:

> > Do we even know that all objects in that slab belong to a certain cgroup?
> > AFAICT the fastpath currently do not allow to make that distinction.
>
> All allocations from a memcg's cache are accounted to the owner memcg,
> so that all objects on the same slab belong to the same memcg, a pointer
> to which can be obtained from the page->slab_cache->memcg_params. At
> least, this is true since commit faebbfe10ec1 ("sl[au]b: charge slabs to
> kmemcg explicitly").

I doubt that. The accounting occurs when a new cpu slab page is allocated.
But the individual allocations in the fastpath are not accounted to a
specific group. Thus allocation in a slab page can belong to various
cgroups.

> > I wish you would find some other way to do this.
>
> The only practical alternative to re-parenting I see right now is
> periodic reaping, but Johannes isn't very fond of it, and his opinion is
> quite justified, because having caches that will never be allocated from
> hanging around indefinitely, only because they have a couple of active
> objects to be freed, doesn't look very good.

If all objects in the cache are in use then the slab page needs to hang
around since the objects presence is required. You may not know exactly
which cgroups these object belong to. The only thing that you may now (if
you keep a list of full slabs) is which cgroup was in use then the
slab page was initially allocated.

Isnt it sufficient to add a counter of full slabs to a cgroup? When you
allocate a new slab page add to the counter. When an object in a slab page
is freed and the slab page goes on a partial list decrement the counter.

That way you can avoid tracking full slabs.

--
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>

  reply	other threads:[~2014-05-16 15:03 UTC|newest]

Thread overview: 31+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-05-13 13:48 [PATCH RFC 0/3] kmemcg slab reparenting Vladimir Davydov
2014-05-13 13:48 ` [PATCH RFC 1/3] slub: keep full slabs on list for per memcg caches Vladimir Davydov
2014-05-14 16:16   ` Christoph Lameter
2014-05-15  6:34     ` Vladimir Davydov
2014-05-15 15:15       ` Christoph Lameter
2014-05-16 13:06         ` Vladimir Davydov
2014-05-16 15:05           ` Christoph Lameter
2014-05-13 13:48 ` [PATCH RFC 2/3] percpu-refcount: allow to get dead reference Vladimir Davydov
2014-05-13 13:48 ` [PATCH RFC 3/3] slub: reparent memcg caches' slabs on memcg offline Vladimir Davydov
2014-05-14 16:20   ` Christoph Lameter
2014-05-15  7:16     ` Vladimir Davydov
2014-05-15 15:16       ` Christoph Lameter
2014-05-16 13:22         ` Vladimir Davydov
2014-05-16 15:03           ` Christoph Lameter [this message]
2014-05-19 15:24             ` Vladimir Davydov
2014-05-19 16:03               ` Christoph Lameter
2014-05-19 18:27                 ` Vladimir Davydov
2014-05-21 13:58                   ` Vladimir Davydov
2014-05-21 14:45                     ` Christoph Lameter
2014-05-21 15:14                       ` Vladimir Davydov
2014-05-22  0:15                         ` Christoph Lameter
2014-05-22 14:07                           ` Vladimir Davydov
2014-05-21 14:41                   ` Christoph Lameter
2014-05-21 15:04                     ` Vladimir Davydov
2014-05-22  0:13                       ` Christoph Lameter
2014-05-22 13:47                         ` Vladimir Davydov
2014-05-22 19:25                           ` Christoph Lameter
2014-05-23 15:26                             ` Vladimir Davydov
2014-05-23 17:45                               ` Christoph Lameter
2014-05-23 19:57                                 ` Vladimir Davydov
2014-05-27 14:38                                   ` Christoph Lameter

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=alpine.DEB.2.10.1405160957100.32249@gentwo.org \
    --to=cl@linux.com \
    --cc=akpm@linux-foundation.org \
    --cc=hannes@cmpxchg.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=mhocko@suse.cz \
    --cc=vdavydov@parallels.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