From: Michal Hocko <mhocko@xxxxxxxx> Subject: memcg: put soft limit reclaim out of way if the excess tree is empty We've had a report about soft lockups caused by lock bouncing in the soft reclaim path: [331404.849734] BUG: soft lockup - CPU#0 stuck for 22s! [kav4proxy-kavic:3128] [331404.849920] RIP: 0010:[<ffffffff81469798>] [<ffffffff81469798>] _raw_spin_lock+0x18/0x20 [331404.849997] Call Trace: [331404.850010] [<ffffffff811557ea>] mem_cgroup_soft_limit_reclaim+0x25a/0x280 [331404.850020] [<ffffffff8111041d>] shrink_zones+0xed/0x200 [331404.850027] [<ffffffff81111a94>] do_try_to_free_pages+0x74/0x320 [331404.850034] [<ffffffff81112072>] try_to_free_pages+0x112/0x180 [331404.850042] [<ffffffff81104a6f>] __alloc_pages_slowpath+0x3ff/0x820 [331404.850049] [<ffffffff81105079>] __alloc_pages_nodemask+0x1e9/0x200 [331404.850056] [<ffffffff81141e01>] alloc_pages_vma+0xe1/0x290 [331404.850064] [<ffffffff8112402f>] do_wp_page+0x19f/0x840 [331404.850071] [<ffffffff811257cd>] handle_pte_fault+0x1cd/0x230 [331404.850079] [<ffffffff8146d3ed>] do_page_fault+0x1fd/0x4c0 [331404.850087] [<ffffffff81469ec5>] page_fault+0x25/0x30 There are no memcgs created so there cannot be any in the soft limit excess obviously: [...] memory 0 1 1 so all this just seems to be mem_cgroup_largest_soft_limit_node trying to get spin_lock_irq(&mctz->lock) just to find out that the soft limit excess tree is empty. This is just pointless wasting of cycles and cache line bouncing during heavy parallel reclaim on large machines. The particular machine wasn't very healthy and most probably suffering from a memory leak which just caused the memory reclaim to trash heavily. But bouncing on the lock certainly didn't help... Fix this by optimistic lockless check and bail out early if the tree is empty. This is theoretically racy but that shouldn't matter all that much. First of all soft limit is a best effort feature and it is slowly getting deprecated and its usage should be really scarce. Bouncing on a lock without a good reason is surely much bigger problem, especially on large CPU machines. Link: http://lkml.kernel.org/r/1470073277-1056-1-git-send-email-mhocko@xxxxxxxxxx Signed-off-by: Michal Hocko <mhocko@xxxxxxxx> Acked-by: Vladimir Davydov <vdavydov@xxxxxxxxxxxxx> Acked-by: Johannes Weiner <hannes@xxxxxxxxxxx> Signed-off-by: Andrew Morton <akpm@xxxxxxxxxxxxxxxxxxxx> --- mm/memcontrol.c | 9 +++++++++ 1 file changed, 9 insertions(+) diff -puN mm/memcontrol.c~memcg-put-soft-limit-reclaim-out-of-way-if-the-excess-tree-is-empty mm/memcontrol.c --- a/mm/memcontrol.c~memcg-put-soft-limit-reclaim-out-of-way-if-the-excess-tree-is-empty +++ a/mm/memcontrol.c @@ -2559,6 +2559,15 @@ unsigned long mem_cgroup_soft_limit_recl return 0; mctz = soft_limit_tree_node(pgdat->node_id); + + /* + * Do not even bother to check the largest node if the root + * is empty. Do it lockless to prevent lock bouncing. Races + * are acceptable as soft limit is best effort anyway. + */ + if (RB_EMPTY_ROOT(&mctz->rb_root)) + return 0; + /* * This loop can run a while, specially if mem_cgroup's continuously * keep exceeding their soft limit and putting the system under _ -- To unsubscribe from this list: send the line "unsubscribe mm-commits" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
