From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751510AbcLEMuB (ORCPT ); Mon, 5 Dec 2016 07:50:01 -0500 Received: from mail-wm0-f68.google.com ([74.125.82.68]:34505 "EHLO mail-wm0-f68.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750841AbcLEMt6 (ORCPT ); Mon, 5 Dec 2016 07:49:58 -0500 Date: Mon, 5 Dec 2016 13:49:55 +0100 From: Michal Hocko To: Balbir Singh Cc: Andrew Morton , Mel Gorman , Johannes Weiner , Vlastimil Babka , linux-mm , LKML , Boris Zhmurov , "Christopher S. Aker" , Donald Buczek , Paul Menzel , "Paul E. McKenney" Subject: Re: [PATCH] mm, vmscan: add cond_resched into shrink_node_memcg Message-ID: <20161205124955.GG30758@dhcp22.suse.cz> References: <20161202095841.16648-1-mhocko@kernel.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.6.0 (2016-04-01) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org [CC Paul - sorry I've tried to save you from more emails...] On Mon 05-12-16 23:44:27, Balbir Singh wrote: > > > > Hi, > > there were multiple reportes of the similar RCU stalls. Only Boris has > > confirmed that this patch helps in his workload. Others might see a > > slightly different issue and that should be investigated if it is the > > case. As pointed out by Paul [1] cond_resched might be not sufficient > > to silence RCU stalls because that would require a real scheduling. > > This is a separate problem, though, and Paul is working with Peter [2] > > to resolve it. > > > > Anyway, I believe that this patch should be a good start because it > > really seems that nr_taken=0 during the LRU isolation can be triggered > > in the real life. All reporters are agreeing to start seeing this issue > > when moving on to 4.8 kernel which might be just a coincidence or a > > different behavior of some subsystem. Well, MM has moved from zone to > > node reclaim but I couldn't have found any direct relation to that > > change. > > > > [1] http://lkml.kernel.org/r/20161130142955.GS3924@linux.vnet.ibm.com > > [2] http://lkml.kernel.org/r/20161201124024.GB3924@linux.vnet.ibm.com > > > > mm/vmscan.c | 2 ++ > > 1 file changed, 2 insertions(+) > > > > diff --git a/mm/vmscan.c b/mm/vmscan.c > > index c05f00042430..c4abf08861d2 100644 > > --- a/mm/vmscan.c > > +++ b/mm/vmscan.c > > @@ -2362,6 +2362,8 @@ static void shrink_node_memcg(struct pglist_data *pgdat, struct mem_cgroup *memc > > } > > } > > > > + cond_resched(); > > + > > I see a cond_resched_rcu_qs() as a part of linux next inside the while > (nr[..]) loop. This is a left over from Paul's initial attempt to fix this issue. I expect him to drop his patch from his tree. He has considered it experimental anyway. > Do we need this as well? Paul is working with Peter to make cond_resched general and cover RCU stalls even when cond_resched doesn't schedule because there is no runnable task. -- Michal Hocko SUSE Labs