linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Johannes Weiner <hannes@cmpxchg.org>
To: Michal Hocko <mhocko@suse.cz>
Cc: Kamezawa Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>,
	Andrew Morton <akpm@linux-foundation.org>,
	Vladimir Davydov <vdavydov@parallels.com>,
	Tejun Heo <tj@kernel.org>, David Miller <davem@davemloft.net>,
	linux-mm@kvack.org, cgroups@vger.kernel.org,
	linux-kernel@vger.kernel.org
Subject: Re: [patch 1/3] mm: embed the memcg pointer directly into struct page
Date: Tue, 4 Nov 2014 09:09:37 -0500	[thread overview]
Message-ID: <20141104140937.GA18602@phnom.home.cmpxchg.org> (raw)
In-Reply-To: <20141104134110.GD22207@dhcp22.suse.cz>

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@cmpxchg.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.

  reply	other threads:[~2014-11-04 14:09 UTC|newest]

Thread overview: 38+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-11-02  3:15 [patch 1/3] mm: embed the memcg pointer directly into struct page Johannes Weiner
2014-11-02  3:15 ` [patch 2/3] mm: page_cgroup: rename file to mm/swap_cgroup.c Johannes Weiner
2014-11-03  4:22   ` David Miller
2014-11-03 16:57   ` Michal Hocko
2014-11-03 17:30   ` Vladimir Davydov
2014-11-04  8:37   ` Kamezawa Hiroyuki
2014-11-02  3:15 ` [patch 3/3] mm: move page->mem_cgroup bad page handling into generic code Johannes Weiner
2014-11-03  4:23   ` David Miller
2014-11-03 16:58   ` Michal Hocko
2014-11-03 17:32   ` Vladimir Davydov
2014-11-03 18:27   ` [patch] mm: move page->mem_cgroup bad page handling into generic code fix Johannes Weiner
2014-11-03 20:10     ` David Miller
2014-11-04  8:39   ` [patch 3/3] mm: move page->mem_cgroup bad page handling into generic code Kamezawa Hiroyuki
2014-11-03  4:22 ` [patch 1/3] mm: embed the memcg pointer directly into struct page David Miller
2014-11-03  8:02 ` Joonsoo Kim
2014-11-03 15:09   ` Johannes Weiner
2014-11-03 16:42     ` David Miller
2014-11-03 17:02     ` Michal Hocko
2014-11-04  0:40     ` Joonsoo Kim
2014-11-03 16:51 ` Michal Hocko
2014-11-03 17:17 ` Michal Hocko
2014-11-03 17:30 ` Vladimir Davydov
2014-11-03 21:06 ` Kirill A. Shutemov
2014-11-03 21:36   ` Johannes Weiner
2014-11-03 21:52     ` Kirill A. Shutemov
2014-11-03 21:58       ` David Miller
2014-11-03 22:36         ` Johannes Weiner
2014-11-04 13:06           ` Michal Hocko
2014-11-04 13:48             ` Johannes Weiner
2014-11-04 14:50               ` Michal Hocko
2014-11-04  8:36 ` Kamezawa Hiroyuki
2014-11-04 13:27   ` Johannes Weiner
2014-11-04 13:41     ` Michal Hocko
2014-11-04 14:09       ` Johannes Weiner [this message]
2014-11-04 15:00         ` Michal Hocko
2014-11-04 17:46           ` Johannes Weiner
2014-11-04 16:34         ` David Miller
2014-11-06 18:55 ` Konstantin Khlebnikov

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20141104140937.GA18602@phnom.home.cmpxchg.org \
    --to=hannes@cmpxchg.org \
    --cc=akpm@linux-foundation.org \
    --cc=cgroups@vger.kernel.org \
    --cc=davem@davemloft.net \
    --cc=kamezawa.hiroyu@jp.fujitsu.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=mhocko@suse.cz \
    --cc=tj@kernel.org \
    --cc=vdavydov@parallels.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).