linux-kernel - Re: [patch 1/3] mm: embed the memcg pointer directly into struct page

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: <20141104140937.GA18602@phnom.home.cmpxchg.org>
Date:	Tue, 4 Nov 2014 09:09:37 -0500
From:	Johannes Weiner <hannes@...xchg.org>
To:	Michal Hocko <mhocko@...e.cz>
Cc:	Kamezawa Hiroyuki <kamezawa.hiroyu@...fujitsu.com>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Vladimir Davydov <vdavydov@...allels.com>,
	Tejun Heo <tj@...nel.org>, David Miller <davem@...emloft.net>,
	linux-mm@...ck.org, cgroups@...r.kernel.org,
	linux-kernel@...r.kernel.org
Subject: Re: [patch 1/3] mm: embed the memcg pointer directly into struct page

On Tue, Nov 04, 2014 at 02:41:10PM +0100, Michal Hocko wrote:
> On Tue 04-11-14 08:27:01, Johannes Weiner wrote:
> > From: Johannes Weiner <hannes@...xchg.org>
> > Subject: [patch] mm: move page->mem_cgroup bad page handling into generic code fix
> > 
> > Remove obsolete memory saving recommendations from the MEMCG Kconfig
> > help text.
> 
> The memory overhead is still there. So I do not think it is good to
> remove the message altogether. The current overhead might be 4 or 8B
> depending on the configuration. What about
> "
> 	Note that setting this option might increase fixed memory
> 	overhead associated with each page descriptor in the system.
> 	The memory overhead depends on the architecture and other
> 	configuration options which have influence on the size and
> 	alignment on the page descriptor (struct page). Namely
> 	CONFIG_SLUB has a requirement for page alignment to two words
> 	which in turn means that 64b systems might not see any memory
> 	overhead as the additional data fits into alignment. On the
> 	other hand 32b systems might see 8B memory overhead.
> "

What difference does it make whether this feature maybe costs an extra
pointer per page or not?  These texts are supposed to help decide with
the selection, but this is not a "good to have, if affordable" type of
runtime debugging option.  You either need cgroup memory accounting
and limiting or not.  There is no possible trade-off to be had.

Slub and numa balancing don't mention this, either, simply because
this cost is negligible or irrelevant when it comes to these knobs.
--
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/