From: Vladimir Davydov <vdavydov@parallels.com>
To: Christoph Lameter <cl@linux.com>
Cc: Johannes Weiner <hannes@cmpxchg.org>,
akpm@linux-foundation.org, mhocko@suse.cz, glommer@gmail.com,
penberg@kernel.org, linux-kernel@vger.kernel.org,
linux-mm@kvack.org, devel@openvz.org
Subject: Re: [PATCH -mm 1/4] memcg, slab: do not schedule cache destruction when last page goes away
Date: Tue, 15 Apr 2014 23:08:27 +0400 [thread overview]
Message-ID: <534D83AB.6040107@parallels.com> (raw)
In-Reply-To: <alpine.DEB.2.10.1404151016400.11231@gentwo.org>
Hi Christoph,
15.04.2014 19:17, Christoph Lameter:
> On Tue, 15 Apr 2014, Vladimir Davydov wrote:
>
>> 2) When freeing an object of a dead memcg cache, initiate thorough check
>> if the cache is really empty and destroy it then. That could be
>> implemented by poking the reaping thread on kfree, and actually does not
>> require the schedule_work in memcg_release_pages IMO.
>
> There is already logic in both slub and slab that does that on cache
> close.
Yeah, but here the question is when we should close caches left after
memcg offline. Obviously we should do it after all objects of such a
cache have gone, but when exactly? Do it immediately after the last
kfree (have to count objects per cache then AFAIU) or may be check
periodically (or on vmpressure) that the cache is empty by issuing
kmem_cache_shrink and looking if memcg_params::nr_pages = 0?
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:[~2014-04-15 19:08 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-04-09 15:02 [PATCH -mm 0/4] memcg-vs-slab cleanup Vladimir Davydov
2014-04-09 15:02 ` [PATCH -mm 1/4] memcg, slab: do not schedule cache destruction when last page goes away Vladimir Davydov
2014-04-15 2:16 ` Johannes Weiner
2014-04-15 6:24 ` Vladimir Davydov
2014-04-15 15:17 ` Christoph Lameter
2014-04-15 19:08 ` Vladimir Davydov [this message]
2014-04-15 19:32 ` Christoph Lameter
2014-04-09 15:02 ` [PATCH -mm 2/4] memcg, slab: merge memcg_{bind,release}_pages to memcg_{un}charge_slab Vladimir Davydov
2014-04-09 15:02 ` [PATCH -mm 3/4] memcg, slab: change memcg::slab_caches_mutex vs slab_mutex locking order Vladimir Davydov
2014-04-09 15:02 ` [PATCH -mm 4/4] memcg, slab: remove memcg_cache_params::destroy work 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=534D83AB.6040107@parallels.com \
--to=vdavydov@parallels.com \
--cc=akpm@linux-foundation.org \
--cc=cl@linux.com \
--cc=devel@openvz.org \
--cc=glommer@gmail.com \
--cc=hannes@cmpxchg.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mhocko@suse.cz \
--cc=penberg@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