From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-lf0-f72.google.com (mail-lf0-f72.google.com [209.85.215.72]) by kanga.kvack.org (Postfix) with ESMTP id B411F6B025E for ; Mon, 1 Aug 2016 11:03:54 -0400 (EDT) Received: by mail-lf0-f72.google.com with SMTP id p85so76969042lfg.3 for ; Mon, 01 Aug 2016 08:03:54 -0700 (PDT) Received: from gum.cmpxchg.org (gum.cmpxchg.org. [85.214.110.215]) by mx.google.com with ESMTPS id p141si16330655wmg.141.2016.08.01.08.03.52 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 01 Aug 2016 08:03:52 -0700 (PDT) Date: Mon, 1 Aug 2016 11:03:43 -0400 From: Johannes Weiner Subject: Re: [PATCH] memcg: put soft limit reclaim out of way if the excess tree is empty Message-ID: <20160801150343.GA7603@cmpxchg.org> References: <1470045621-14335-1-git-send-email-mhocko@kernel.org> <20160801135757.GB19395@esperanza> <20160801141227.GI13544@dhcp22.suse.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20160801141227.GI13544@dhcp22.suse.cz> Sender: owner-linux-mm@kvack.org List-ID: To: Michal Hocko Cc: Vladimir Davydov , Andrew Morton , linux-mm@kvack.org, LKML On Mon, Aug 01, 2016 at 04:12:28PM +0200, Michal Hocko wrote: > From: Michal Hocko > Date: Mon, 1 Aug 2016 10:42:06 +0200 > Subject: [PATCH] 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:[] [] _raw_spin_lock+0x18/0x20 > [331404.849997] Call Trace: > [331404.850010] [] mem_cgroup_soft_limit_reclaim+0x25a/0x280 > [331404.850020] [] shrink_zones+0xed/0x200 > [331404.850027] [] do_try_to_free_pages+0x74/0x320 > [331404.850034] [] try_to_free_pages+0x112/0x180 > [331404.850042] [] __alloc_pages_slowpath+0x3ff/0x820 > [331404.850049] [] __alloc_pages_nodemask+0x1e9/0x200 > [331404.850056] [] alloc_pages_vma+0xe1/0x290 > [331404.850064] [] do_wp_page+0x19f/0x840 > [331404.850071] [] handle_pte_fault+0x1cd/0x230 > [331404.850079] [] do_page_fault+0x1fd/0x4c0 > [331404.850087] [] 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 waisting 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... > > Introduce soft_limit_tree_empty which does the 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. > > Signed-off-by: Michal Hocko > --- > mm/memcontrol.c | 8 ++++++++ > 1 file changed, 8 insertions(+) > > diff --git a/mm/memcontrol.c b/mm/memcontrol.c > index c265212bec8c..c0b57b6a194e 100644 > --- a/mm/memcontrol.c > +++ b/mm/memcontrol.c > @@ -2543,6 +2543,11 @@ static int mem_cgroup_resize_memsw_limit(struct mem_cgroup *memcg, > return ret; > } > > +static inline bool soft_limit_tree_empty(struct mem_cgroup_tree_per_node *mctz) > +{ > + return RB_EMPTY_ROOT(&mctz->rb_root); > +} Can you please fold this into the caller? It should be obvious enough. Other than that, this patch makes sense to me. Acked-by: Johannes Weiner -- 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: email@kvack.org