linux-kernel - Re: [PATCH v6 00/29] kmem controller for memcg.

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:	Fri, 2 Nov 2012 16:06:38 -0700
From:	Tejun Heo <tj@...nel.org>
To:	JoonSoo Kim <js1304@...il.com>
Cc:	Glauber Costa <glommer@...allels.com>,
	Andrew Morton <akpm@...ux-foundation.org>, linux-mm@...ck.org,
	linux-kernel@...r.kernel.org, kamezawa.hiroyu@...fujitsu.com,
	Johannes Weiner <hannes@...xchg.org>,
	Michal Hocko <mhocko@...e.cz>,
	Christoph Lameter <cl@...ux.com>,
	Pekka Enberg <penberg@...nel.org>,
	David Rientjes <rientjes@...gle.com>,
	Greg Thelen <gthelen@...gle.com>
Subject: Re: [PATCH v6 00/29] kmem controller for memcg.

Hey, Joonsoo.

On Sat, Nov 03, 2012 at 04:25:59AM +0900, JoonSoo Kim wrote:
> I am worrying about data cache footprint which is possibly caused by
> this patchset, especially slab implementation.
> If there are several memcg cgroups, each cgroup has it's own kmem_caches.
> When each group do slab-intensive job hard, data cache may be overflowed easily,
> and cache miss rate will be high, therefore this would decrease system
> performance highly.

It would be nice to be able to remove such overhead too, but the
baselines for cgroup implementations (well, at least the ones that I
think important) in somewhat decreasing priority are...

1. Don't over-complicate the target subsystem.

2. Overhead when cgroup is not used should be minimal.  Prefereably to
   the level of being unnoticeable.

3. Overhead while cgroup is being actively used should be reasonable.

If you wanna split your system into N groups and maintain memory
resource segregation among them, I don't think it's unreasonable to
ask for paying data cache footprint overhead.

So, while improvements would be nice, I wouldn't consider overheads of
this type as a blocker.

Thanks.

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