From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932402AbcKUO3G (ORCPT ); Mon, 21 Nov 2016 09:29:06 -0500 Received: from mx0b-001b2d01.pphosted.com ([148.163.158.5]:33869 "EHLO mx0a-001b2d01.pphosted.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S932286AbcKUO3D (ORCPT ); Mon, 21 Nov 2016 09:29:03 -0500 Date: Mon, 21 Nov 2016 06:29:01 -0800 From: "Paul E. McKenney" To: Michal Hocko Cc: Paul Menzel , linux-xfs@vger.kernel.org, linux-kernel@vger.kernel.org, Josh Triplett , dvteam@molgen.mpg.de Subject: Re: INFO: rcu_sched detected stalls on CPUs/tasks with `kswapd` and `mem_cgroup_shrink_node` Reply-To: paulmck@linux.vnet.ibm.com References: <24c226a5-1a4a-173e-8b4e-5107a2baac04@molgen.mpg.de> <28a9fabb-c9fe-c865-016a-467a4d5e2a34@molgen.mpg.de> <20161108170340.GB4127@linux.vnet.ibm.com> <6c717122-e671-b086-77ed-4b3c26398564@molgen.mpg.de> <20161108183938.GD4127@linux.vnet.ibm.com> <9f87f8f0-9d0f-f78f-8dca-993b09b19a69@molgen.mpg.de> <20161116173036.GK3612@linux.vnet.ibm.com> <20161121134130.GB18112@dhcp22.suse.cz> <20161121140122.GU3612@linux.vnet.ibm.com> <20161121141818.GD18112@dhcp22.suse.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20161121141818.GD18112@dhcp22.suse.cz> User-Agent: Mutt/1.5.21 (2010-09-15) X-TM-AS-GCONF: 00 X-Content-Scanned: Fidelis XPS MAILER x-cbid: 16112114-0012-0000-0000-0000113014CD X-IBM-SpamModules-Scores: X-IBM-SpamModules-Versions: BY=3.00006117; HX=3.00000240; KW=3.00000007; PH=3.00000004; SC=3.00000189; SDB=6.00783443; UDB=6.00378340; IPR=6.00561062; BA=6.00004898; NDR=6.00000001; ZLA=6.00000005; ZF=6.00000009; ZB=6.00000000; ZP=6.00000000; ZH=6.00000000; ZU=6.00000002; MB=3.00013395; XFM=3.00000011; UTC=2016-11-21 14:29:01 X-IBM-AV-DETECTION: SAVI=unused REMOTE=unused XFE=unused x-cbparentid: 16112114-0013-0000-0000-000047595E24 Message-Id: <20161121142901.GV3612@linux.vnet.ibm.com> X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:,, definitions=2016-11-21_12:,, signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1609300000 definitions=main-1611210252 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Nov 21, 2016 at 03:18:19PM +0100, Michal Hocko wrote: > On Mon 21-11-16 06:01:22, Paul E. McKenney wrote: > > On Mon, Nov 21, 2016 at 02:41:31PM +0100, Michal Hocko wrote: > [...] > > > To the patch. I cannot say I would like it. cond_resched_rcu_qs sounds > > > way too lowlevel for this usage. If anything cond_resched somewhere inside > > > mem_cgroup_iter would be more appropriate to me. > > > > Like this? > > > > Thanx, Paul > > > > ------------------------------------------------------------------------ > > > > diff --git a/mm/memcontrol.c b/mm/memcontrol.c > > index ae052b5e3315..81cb30d5b2fc 100644 > > --- a/mm/memcontrol.c > > +++ b/mm/memcontrol.c > > @@ -867,6 +867,7 @@ struct mem_cgroup *mem_cgroup_iter(struct mem_cgroup *root, > > out: > > if (prev && prev != root) > > css_put(&prev->css); > > + cond_resched_rcu_qs(); > > I still do not understand why should we play with _rcu_qs at all and a > regular cond_resched is not sufficient. Anyway I would have to double > check whether we can do cond_resched in the iterator. I do not remember > having users which are atomic but I might be easily wrong here. Before > we touch this code, though, I would really like to understand what is > actually going on here because as I've already pointed out we should > have some resched points in the reclaim path. If there is a tight loop in the kernel, cond_resched() will ensure that other tasks get a chance to run, but if there are no such tasks, it does nothing to give RCU the quiescent state that it needs from time to time. So if there is a possibility of a long-running in-kernel loop without preemption by some other task, cond_resched_rcu_qs() is required. I welcome your deeper investigation -- I am very much treating symptoms here, which might or might not have any relationship to fixing underlying problems. Thanx, Paul