linux-kernel - Re: [PATCH 6/8] mm: memcontrol: move kmem accounting code to CONFIG

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: <20151210140012.GA21987@cmpxchg.org>
Date:	Thu, 10 Dec 2015 09:00:12 -0500
From:	Johannes Weiner <hannes@...xchg.org>
To:	Michal Hocko <mhocko@...nel.org>
Cc:	Andrew Morton <akpm@...ux-foundation.org>,
	Vladimir Davydov <vdavydov@...tuozzo.com>, linux-mm@...ck.org,
	cgroups@...r.kernel.org, linux-kernel@...r.kernel.org,
	kernel-team@...com
Subject: Re: [PATCH 6/8] mm: memcontrol: move kmem accounting code to
 CONFIG_MEMCG

On Thu, Dec 10, 2015 at 02:17:18PM +0100, Michal Hocko wrote:
> On Tue 08-12-15 13:34:23, Johannes Weiner wrote:
> > The cgroup2 memory controller will account important in-kernel memory
> > consumers per default. Move all necessary components to CONFIG_MEMCG.
> 
> Hmm, that bloats the kernel also for users who are not using cgroup2
> and have CONFIG_MEMCG_KMEM disabled.

Huh? The clock is ticking for them. We'll keep the original cgroup
interface around for backwards compatibility as long as we think there
are activer users, but this is not the time to microoptimize v1. A
slight increase to kernel size is unfortunate, but I don't think this
could be considered a regression in the sense that it breaks anything.

I'm more concerned with cgroup2 users having to pay the excessive cost
of v1-only features, like the entire soft limit implementation, charge
migration, which also has its fangs in VM hotpaths, the eventfd stuff,
arbitrarily-configurable usage thresholds. That's a *ton* of code. If
you want to tackle kernel bloat, grouping this stuff all together and
slapping a CONFIG_MEMCG_LEGACY around it would be a real step forward.
--
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/