Received: by 2002:a05:6a10:6006:0:0:0:0 with SMTP id w6csp190146pxa; Wed, 26 Aug 2020 08:07:14 -0700 (PDT) X-Google-Smtp-Source: ABdhPJxInuklh4N4z/HZt94kziBmp6yLI9jFPw0iiwwnFVjH3aFv3a6P3+yCpIoAlvZAo8wjjXGX X-Received: by 2002:a17:906:71c7:: with SMTP id i7mr15537243ejk.245.1598454434242; Wed, 26 Aug 2020 08:07:14 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1598454434; cv=none; d=google.com; s=arc-20160816; b=kuJtSKWMVSKbu7fKVZKy4fAbhJPAr+sf3qOYOa89XdJFD38FIf1KR6X1XmpPSYcvwi HFmv0bwsYPd4zbQYLk5V7J7DUQqtosZrQGD0tGmyl052aukDQ93aFm83kGZU/mUZVhW8 TizWuJjptu+//TSovm9E0C01UcaWn7N/R8KMLScG048BOC0nwRfP6ALW/+f2oyKC1h4B ifSIoigD0WCKai7nUXs+CEdkyP3rbmP0b2jm+DIhIEhRzZWBNdBPg8r3vGY+WAMOqYBQ FMEZMM5cE3kAeSUcnJAYyXSdSlHzqkmYrwhJ8nP8r01wMX1p/DxkRrh52APU+nHFjD5/ VIfw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:in-reply-to:content-disposition :mime-version:references:message-id:subject:cc:to:from:date; bh=VGCNH5nHjmJEdsKk/v5nojjil5sGb2WthoRXatjiM70=; b=by+rW5MNJoNhb/x3Uv45yxEgGZWXkFLcML4SB2tQON5RpFyIlqbU+fTUopnA9s7HZJ XLwFmKYszOdYAGEY/CEFsp9qajxIHaLe1OUTKqb8TzUu6zAU43MqnNcWads7q87fihlx O89knDQ7LH9ToLRcuS72MHDEDM77t7ssjN8x2XzExFeGM8gqzaJ2Pu94bnMjWPOe+PF9 OlC4RhSaoU/NTG0okfvgRetlw5QtYmhkajIoQelnMJOquwqURMpZVTyesHq3HAcqtWnm ogRlVUntECjdmOGty6l3QM261jKRy7WO9C7vA96373VLoFZqEQU+wgu9bW0SWnkK1Q78 oPnQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id e3si1487247edn.368.2020.08.26.08.06.50; Wed, 26 Aug 2020 08:07:14 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727875AbgHZPFY (ORCPT + 99 others); Wed, 26 Aug 2020 11:05:24 -0400 Received: from mx2.suse.de ([195.135.220.15]:45004 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727814AbgHZPFU (ORCPT ); Wed, 26 Aug 2020 11:05:20 -0400 X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.221.27]) by mx2.suse.de (Postfix) with ESMTP id 511F9AC46; Wed, 26 Aug 2020 15:05:50 +0000 (UTC) Date: Wed, 26 Aug 2020 17:05:17 +0200 From: Michal Hocko To: Xunlei Pang Cc: Johannes Weiner , Andrew Morton , Vladimir Davydov , linux-kernel@vger.kernel.org, linux-mm@kvack.org Subject: Re: [PATCH v2] mm: memcg: Fix memcg reclaim soft lockup Message-ID: <20200826150517.GS22869@dhcp22.suse.cz> References: <1598449622-108748-1-git-send-email-xlpang@linux.alibaba.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1598449622-108748-1-git-send-email-xlpang@linux.alibaba.com> Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed 26-08-20 21:47:02, Xunlei Pang wrote: > We've met softlockup with "CONFIG_PREEMPT_NONE=y", when > the target memcg doesn't have any reclaimable memory. > > It can be easily reproduced as below: > watchdog: BUG: soft lockup - CPU#0 stuck for 111s![memcg_test:2204] > CPU: 0 PID: 2204 Comm: memcg_test Not tainted 5.9.0-rc2+ #12 > Call Trace: > shrink_lruvec+0x49f/0x640 > shrink_node+0x2a6/0x6f0 > do_try_to_free_pages+0xe9/0x3e0 > try_to_free_mem_cgroup_pages+0xef/0x1f0 > try_charge+0x2c1/0x750 > mem_cgroup_charge+0xd7/0x240 > __add_to_page_cache_locked+0x2fd/0x370 > add_to_page_cache_lru+0x4a/0xc0 > pagecache_get_page+0x10b/0x2f0 > filemap_fault+0x661/0xad0 > ext4_filemap_fault+0x2c/0x40 > __do_fault+0x4d/0xf9 > handle_mm_fault+0x1080/0x1790 > > It only happens on our 1-vcpu instances, because there's no chance > for oom reaper to run to reclaim the to-be-killed process. > > Add cond_resched() at the upper shrink_node_memcgs() to solve this > issue, and any other possible issue like meomry.min protection. I would just add " This will mean that we will get a scheduling point for each memcg in the reclaimed hierarchy without any dependency on the reclaimable memory in that memcg thus making it more predictable. " > Suggested-by: Michal Hocko > Signed-off-by: Xunlei Pang Acked-by: Michal Hocko Thanks! > --- > mm/vmscan.c | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/mm/vmscan.c b/mm/vmscan.c > index 99e1796..bbdc38b 100644 > --- a/mm/vmscan.c > +++ b/mm/vmscan.c > @@ -2617,6 +2617,8 @@ static void shrink_node_memcgs(pg_data_t *pgdat, struct scan_control *sc) > > mem_cgroup_calculate_protection(target_memcg, memcg); > > + cond_resched(); > + > if (mem_cgroup_below_min(memcg)) { > /* > * Hard protection. > -- > 1.8.3.1 -- Michal Hocko SUSE Labs