From: Michal Hocko <mhocko@suse.cz>
To: Johannes Weiner <hannes@cmpxchg.org>
Cc: linux-mm@kvack.org, Greg Thelen <gthelen@google.com>,
Dave Hansen <dave@sr71.net>,
cgroups@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [patch] mm: memcontrol: lockless page counters
Date: Tue, 23 Sep 2014 16:28:16 +0200 [thread overview]
Message-ID: <20140923142816.GC10046@dhcp22.suse.cz> (raw)
In-Reply-To: <20140923140526.GA15014@cmpxchg.org>
On Tue 23-09-14 10:05:26, Johannes Weiner wrote:
[...]
> That's one way to put it. But the way I see it is that I remove a
> generic resource counter and replace it with a pure memory counter
> which I put where we account and limit memory - with one exception
> that is hardly worth creating a dedicated library file for.
So you completely seem to ignore people doing CONFIG_CGROUP_HUGETLB &&
!CONFIG_MEMCG without any justification and hiding it behind performance
improvement which those users even didn't ask for yet.
All that just to not have one additional header and c file hidden by
CONFIG_PAGE_COUNTER selected by both controllers. No special
configuration option is really needed for CONFIG_PAGE_COUNTER.
> I only explained my plans of merging all memory controllers because I
> assumed we could ever be on the same page when it comes to this code.
I doubt this is a good plan but I might be wrong here. The main thing
stays there is no good reason to make hugetlb depend on memcg right now
and such a change _shouldn't_ be hidden behind an unrelated change. From
hugetlb container point of view this is just a different counter which
doesn't depend on memcg. I am really surprised you are pushing for this
so hard right now because it only distracts from the main motivation of
your patch.
> But regardless of that, my approach immediately simplifies Kconfig,
> Makefiles, #includes, and you haven't made a good point why the
> hugetlb controller depending on memcg would harm anybody in real life.
Usecases for hugetlb and memcg controllers have basically zero overlap
they simply manage different resources and so it is natural to use one
without the other.
--
Michal Hocko
SUSE Labs
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
next prev parent reply other threads:[~2014-09-23 14:28 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-09-19 13:22 [patch] mm: memcontrol: lockless page counters Johannes Weiner
2014-09-19 13:29 ` Johannes Weiner
2014-09-22 14:41 ` Vladimir Davydov
2014-09-22 18:57 ` Johannes Weiner
2014-09-23 11:06 ` Vladimir Davydov
2014-09-23 13:28 ` Johannes Weiner
2014-09-23 15:21 ` Vladimir Davydov
2014-09-23 17:05 ` Johannes Weiner
2014-09-24 8:02 ` Vladimir Davydov
2014-09-24 13:33 ` Michal Hocko
2014-09-24 16:51 ` Johannes Weiner
2014-09-24 14:16 ` Michal Hocko
2014-09-24 17:00 ` Johannes Weiner
2014-09-25 13:07 ` Michal Hocko
2014-09-22 14:44 ` Michal Hocko
2014-09-22 15:50 ` Johannes Weiner
2014-09-22 17:28 ` Michal Hocko
2014-09-22 19:58 ` Johannes Weiner
2014-09-23 13:25 ` Michal Hocko
2014-09-23 14:05 ` Johannes Weiner
2014-09-23 14:28 ` Michal Hocko [this message]
2014-09-23 22:33 ` David Rientjes
2014-09-23 7:46 ` Kamezawa Hiroyuki
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=20140923142816.GC10046@dhcp22.suse.cz \
--to=mhocko@suse.cz \
--cc=cgroups@vger.kernel.org \
--cc=dave@sr71.net \
--cc=gthelen@google.com \
--cc=hannes@cmpxchg.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
/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).