linux-kernel - Re: [PATCH -mm 8/8] slab: recharge slab pages to the allocating memory cgroup

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:	Thu, 6 Nov 2014 09:01:52 -0600 (CST)
From:	Christoph Lameter <cl@...ux.com>
To:	Vladimir Davydov <vdavydov@...allels.com>
cc:	Andrew Morton <akpm@...ux-foundation.org>,
	Johannes Weiner <hannes@...xchg.org>,
	Michal Hocko <mhocko@...e.cz>,
	Pekka Enberg <penberg@...nel.org>,
	David Rientjes <rientjes@...gle.com>,
	Joonsoo Kim <iamjoonsoo.kim@....com>, linux-mm@...ck.org,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH -mm 8/8] slab: recharge slab pages to the allocating
 memory cgroup

On Thu, 6 Nov 2014, Vladimir Davydov wrote:

> I call memcg_kmem_recharge_slab only on alloc path. Free path isn't
> touched. The overhead added is one function call. The function only
> reads and compares two pointers under RCU most of time. This is
> comparable to the overhead introduced by memcg_kmem_get_cache, which is
> called in slab_alloc/slab_alloc_node earlier.

Right maybe remove those too? Things seem to be accumulating in the hot
path which is bad. There is a slow path where these things can be added
and also a page based even slower path for statistics keeping.

The approach in SLUB is to do accounting on a slab page basis. Also memory
policies are applied at page granularity not object granularity.

> Anyways, if you think this is unacceptable, I don't mind dropping the
> whole patch set and thinking more on how to fix this per-memcg caches
> trickery. What do you think?

Maybe its possible to just use slab page accounting instead of object
accounting? Reduces overhead significantly. There may be some fuzz here
with occasional object accounted in the wrong way (which is similar to how
memory policies and other methods work) but it has been done before and
works ok.

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