linux-kernel - Re: [PATCH -mm 1/4] memcg, slab: do not schedule cache destruction when last page goes away

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Tue, 15 Apr 2014 23:08:27 +0400
From:	Vladimir Davydov <vdavydov@...allels.com>
To:	Christoph Lameter <cl@...ux.com>
CC:	Johannes Weiner <hannes@...xchg.org>, <akpm@...ux-foundation.org>,
	<mhocko@...e.cz>, <glommer@...il.com>, <penberg@...nel.org>,
	<linux-kernel@...r.kernel.org>, <linux-mm@...ck.org>,
	<devel@...nvz.org>
Subject: Re: [PATCH -mm 1/4] memcg, slab: do not schedule cache destruction
 when last page goes away

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 from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/