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: linux-mm@kvack.org, Hugh Dickins <hughd@google.com>,
	Tejun Heo <tj@kernel.org>,
	cgroups@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [patch 8/9] mm: memcontrol: rewrite charge API
Date: Tue, 27 May 2014 16:05:16 -0400	[thread overview]
Message-ID: <20140527200516.GE2878@cmpxchg.org> (raw)
In-Reply-To: <20140523145413.GF22135@dhcp22.suse.cz>

On Fri, May 23, 2014 at 04:54:13PM +0200, Michal Hocko wrote:
> On Wed 30-04-14 16:25:42, Johannes Weiner wrote:
> > The memcg charge API charges pages before they are rmapped - i.e. have
> > an actual "type" - and so every callsite needs its own set of charge
> > and uncharge functions to know what type is being operated on.
> > 
> > Rewrite the charge API to provide a generic set of try_charge(),
> > commit_charge() and cancel_charge() transaction operations, much like
> > what's currently done for swap-in:
> > 
> >   mem_cgroup_try_charge() attempts to reserve a charge, reclaiming
> >   pages from the memcg if necessary.
> > 
> >   mem_cgroup_commit_charge() commits the page to the charge once it
> >   has a valid page->mapping and PageAnon() reliably tells the type.
> > 
> >   mem_cgroup_cancel_charge() aborts the transaction.
> > 
> > As pages need to be committed after rmap is established but before
> > they are added to the LRU, page_add_new_anon_rmap() must stop doing
> > LRU additions again.  Factor lru_cache_add_active_or_unevictable().
> > 
> > The order of functions in mm/memcontrol.c is entirely random, so this
> > new charge interface is implemented at the end of the file, where all
> > new or cleaned up, and documented code should go from now on.
> 
> I would prefer moving them after refactoring because the reviewing is
> really harder this way. If such moving is needed at all.

I find it incredibly cumbersome to work with this code because of the
ordering.  Sure, you use the search function of the editor, but you
don't even know whether to look above or below, half of the hits are
forward declarations etc.  Crappy code attracts more crappy code, so I
feel strongly that we clean this up and raise the bar for the future.

As to the ordering: I chose this way because this really is a
fundamental rewrite, and I figured it would be *easier* to read if you
have the entire relevant code show up in the diff.  I.e. try_charge()
is fully included, right next to its API entry function.

If this doesn't work for you - the reviewer - I'm happy to change it
around and move the code separately.

> size is saying the code is slightly bigger:
>    text    data     bss     dec     hex filename
>  487977   84898   45984  618859   9716b mm/built-in.o.7
>  488276   84898   45984  619158   97296 mm/built-in.o.8
> 
> No biggie though.
> 
> It is true it get's rid of ~80LOC in memcontrol.c but it adds some more
> outside of memcg. Most of the charging paths didn't get any easier, they
> already know the type and they have to make sure they even commit the
> charge now.
> 
> But maybe it is just me feeling that now that we have
> mem_cgroup_charge_{anon,file,swapin} the API doesn't look so insane
> anymore and so I am not tempted to change it that much.

I should have been a little clearer in the changelog: this is mainly
to make sure we never commit pages before their rmapping is
established so that not only charging, but also uncharging can be
drastically simplified.

You already noticed that when looking at the next patch, but I'll make
sure to mention it here as well.

  parent reply	other threads:[~2014-05-27 20:05 UTC|newest]

Thread overview: 35+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-04-30 20:25 [patch 0/9] mm: memcontrol: naturalize charge lifetime Johannes Weiner
2014-04-30 20:25 ` [patch 1/9] mm: memcontrol: fold mem_cgroup_do_charge() Johannes Weiner
2014-04-30 20:25 ` [patch 2/9] mm: memcontrol: rearrange charging fast path Johannes Weiner
2014-05-07 14:33   ` Michal Hocko
2014-05-08 18:22     ` Johannes Weiner
2014-05-12  7:59       ` Michal Hocko
2014-04-30 20:25 ` [patch 3/9] mm: memcontrol: retry reclaim for oom-disabled and __GFP_NOFAIL charges Johannes Weiner
2014-05-07 14:43   ` Michal Hocko
2014-05-08 18:28     ` Johannes Weiner
2014-04-30 20:25 ` [patch 4/9] mm: memcontrol: catch root bypass in move precharge Johannes Weiner
2014-05-07 14:55   ` Michal Hocko
2014-05-08 18:30     ` Johannes Weiner
2014-04-30 20:25 ` [patch 5/9] mm: memcontrol: use root_mem_cgroup res_counter Johannes Weiner
2014-05-07 15:14   ` Michal Hocko
2014-04-30 20:25 ` [patch 6/9] mm: memcontrol: remove ordering between pc->mem_cgroup and PageCgroupUsed Johannes Weiner
2014-05-23 13:20   ` Michal Hocko
2014-05-27 19:45     ` Johannes Weiner
2014-05-28 11:31       ` Michal Hocko
2014-04-30 20:25 ` [patch 7/9] mm: memcontrol: do not acquire page_cgroup lock for kmem pages Johannes Weiner
2014-05-23 13:39   ` Michal Hocko
2014-05-23 13:40     ` Michal Hocko
2014-05-23 14:29     ` Vladimir Davydov
2014-05-27 19:53     ` Johannes Weiner
2014-05-28 11:33       ` Michal Hocko
2014-04-30 20:25 ` [patch 8/9] mm: memcontrol: rewrite charge API Johannes Weiner
2014-05-23 14:18   ` Michal Hocko
2014-05-23 14:54   ` Michal Hocko
2014-05-23 15:18     ` Michal Hocko
2014-05-27 20:05     ` Johannes Weiner [this message]
2014-05-28 11:37       ` Michal Hocko
2014-04-30 20:25 ` [patch 9/9] mm: memcontrol: rewrite uncharge API Johannes Weiner
2014-05-04 14:32   ` Johannes Weiner
2014-05-27  7:43   ` Kamezawa Hiroyuki
2014-05-27 18:59     ` Johannes Weiner
2014-05-02 11:26 ` [patch 0/9] mm: memcontrol: naturalize charge lifetime Michal Hocko

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=20140527200516.GE2878@cmpxchg.org \
    --to=hannes@cmpxchg.org \
    --cc=cgroups@vger.kernel.org \
    --cc=hughd@google.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=mhocko@suse.cz \
    --cc=tj@kernel.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).