[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-Id: <1387295130-19771-1-git-send-email-mhocko@suse.cz>
Date: Tue, 17 Dec 2013 16:45:25 +0100
From: Michal Hocko <mhocko@...e.cz>
To: Johannes Weiner <hannes@...xchg.org>
Cc: Andrew Morton <akpm@...ux-foundation.org>,
KAMEZAWA Hiroyuki <kamezawa.hiroyu@...fujitsu.com>,
KOSAKI Motohiro <kosaki.motohiro@...fujitsu.com>,
LKML <linux-kernel@...r.kernel.org>, <linux-mm@...ck.org>
Subject: [RFC] memcg: some charge path cleanups + css offline vs. charge race fix
Hi,
the first three patches are an attempt to clean up memcg charging path a
bit. I am already fed up about all the different combinations of mm vs.
memcgp parameters so I have split up the function into two parts:
* charge mm
* charge a known memcg
More details are in the patch 1. I think that this makes more sense.
It was also quite surprising that just the code reordering without any
functional changes made the code smaller by 600B.
Second patch is just a trivial follow up, shouldn't be controversial.
The third one tries to remove an exception (bypass) path which was there
from the early days but it never made any sense to me. It always made me
confused so I would more than happy to ditch it.
Finally patch#4 addresses memcg charge vs. memcg_offline race + #5
reverts the workaround which has been merged as a first aid.
What do you think?
Based on the current mmotm (mmotm-2013-12-16-14-29-6)
Michal Hocko (5):
memcg: cleanup charge routines
memcg: move stock charge into __mem_cgroup_try_charge_memcg
memcg: mm == NULL is not allowed for mem_cgroup_try_charge_mm
memcg: make sure that memcg is not offline when charging
Revert "mm: memcg: fix race condition between memcg teardown and swapin"
Diffstat:
mm/memcontrol.c | 361 +++++++++++++++++++++++++++++---------------------------
1 file changed, 185 insertions(+), 176 deletions(-)
--
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/
Powered by blists - more mailing lists