linux-kernel - Re: [PATCH v6 25/29] memcg/sl[au]b: shrink dead caches

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]

Message-Id: <20121105164813.2eba5ecb.akpm@linux-foundation.org>
Date:	Mon, 5 Nov 2012 16:48:13 -0800
From:	Andrew Morton <akpm@...ux-foundation.org>
To:	Glauber Costa <glommer@...allels.com>
Cc:	<linux-mm@...ck.org>, <linux-kernel@...r.kernel.org>,
	<kamezawa.hiroyu@...fujitsu.com>,
	Johannes Weiner <hannes@...xchg.org>,
	Tejun Heo <tj@...nel.org>, Michal Hocko <mhocko@...e.cz>,
	Christoph Lameter <cl@...ux.com>,
	Pekka Enberg <penberg@...nel.org>,
	David Rientjes <rientjes@...gle.com>,
	Pekka Enberg <penberg@...helsinki.fi>,
	Suleiman Souhlal <suleiman@...gle.com>
Subject: Re: [PATCH v6 25/29] memcg/sl[au]b: shrink dead caches

On Thu,  1 Nov 2012 16:07:41 +0400
Glauber Costa <glommer@...allels.com> wrote:

> This means that when we destroy a memcg cache that happened to be empty,
> those caches may take a lot of time to go away: removing the memcg
> reference won't destroy them - because there are pending references, and
> the empty pages will stay there, until a shrinker is called upon for any
> reason.
> 
> In this patch, we will call kmem_cache_shrink for all dead caches that
> cannot be destroyed because of remaining pages. After shrinking, it is
> possible that it could be freed. If this is not the case, we'll schedule
> a lazy worker to keep trying.

This patch is really quite nasty.  We poll the cache once per minute
trying to shrink then free it?  a) it gives rise to concerns that there
will be scenarios where the system could suffer unlimited memory windup
but mainly b) it's just lame.

The kernel doesn't do this sort of thing.  The kernel tries to be
precise: in a situation like this we keep track of the number of
outstanding objects and when that falls to zero, we free their
container synchronously.  If those objects are normally left floating
around in an allocated but reclaimable state then we can address that
by synchronously freeing them if their container has been destroyed.

Or something like that.  If it's something else then fine, but not this.

What do we need to do to fix this?

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