From mboxrd@z Thu Jan 1 00:00:00 1970 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S933348AbeAIQAw (ORCPT + 1 other); Tue, 9 Jan 2018 11:00:52 -0500 Received: from mx0b-001b2d01.pphosted.com ([148.163.158.5]:52626 "EHLO mx0a-001b2d01.pphosted.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S932718AbeAIQAu (ORCPT ); Tue, 9 Jan 2018 11:00:50 -0500 Date: Tue, 9 Jan 2018 08:00:22 -0800 From: "Paul E. McKenney" To: Tejun Heo Cc: Prateek Sood , Peter Zijlstra , avagin@gmail.com, mingo@kernel.org, linux-kernel@vger.kernel.org, cgroups@vger.kernel.org, sramana@codeaurora.org Subject: Re: [PATCH] cgroup/cpuset: fix circular locking dependency Reply-To: paulmck@linux.vnet.ibm.com References: <20180102174408.GM7829@linux.vnet.ibm.com> <20180102180119.GA1355@linux.vnet.ibm.com> <20180108122823.GL3668920@devbig577.frc2.facebook.com> <20180108225238.GN9671@linux.vnet.ibm.com> <20180109003127.GA30224@linux.vnet.ibm.com> <20180109034211.GC3668920@devbig577.frc2.facebook.com> <20180109042016.GR9671@linux.vnet.ibm.com> <20180109134448.GE3668920@devbig577.frc2.facebook.com> <20180109152112.GT9671@linux.vnet.ibm.com> <20180109153752.GI3668920@devbig577.frc2.facebook.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20180109153752.GI3668920@devbig577.frc2.facebook.com> User-Agent: Mutt/1.5.21 (2010-09-15) X-TM-AS-GCONF: 00 x-cbid: 18010915-0024-0000-0000-0000030E9569 X-IBM-SpamModules-Scores: X-IBM-SpamModules-Versions: BY=3.00008347; HX=3.00000241; KW=3.00000007; PH=3.00000004; SC=3.00000245; SDB=6.00972550; UDB=6.00492707; IPR=6.00752501; BA=6.00005768; NDR=6.00000001; ZLA=6.00000005; ZF=6.00000009; ZB=6.00000000; ZP=6.00000000; ZH=6.00000000; ZU=6.00000002; MB=3.00018941; XFM=3.00000015; UTC=2018-01-09 15:59:41 X-IBM-AV-DETECTION: SAVI=unused REMOTE=unused XFE=unused x-cbparentid: 18010915-0025-0000-0000-00004692B80C Message-Id: <20180109160022.GW9671@linux.vnet.ibm.com> X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:,, definitions=2018-01-09_09:,, signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 spamscore=0 suspectscore=0 malwarescore=0 lowpriorityscore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1709140000 definitions=main-1801090226 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Return-Path: On Tue, Jan 09, 2018 at 07:37:52AM -0800, Tejun Heo wrote: > Hello, Paul. > > On Tue, Jan 09, 2018 at 07:21:12AM -0800, Paul E. McKenney wrote: > > > The code was previously using both system_power_efficient_wq and > > > system_workqueue (for the expedited path). I guess the options were > > > either using two workqueues or dropping POWER_EFFICIENT. I have no > > > idea how big an impact this will make or whether it'd even be > > > noticeable but maybe it'd be worthwhile to mention that in the > > > description? > > > > Good point! How about if I change the last paragraph of the commit > > log to read as follows? > > > > Thanx, Paul > > > > ------------------------------------------------------------------------ > > > > This commit also causes SRCU to use this new RCU-specific > > workqueue_struct. Note that SRCU's use of workqueues never blocks them > > waiting for readers, so this should be safe from a forward-progress > > viewpoint. Note that this moves SRCU from system_power_efficient_wq > > to a normal workqueue. In the unlikely event that this results in > > measurable degradation, a separate power-efficient workqueue will be > > creates for SRCU. > > Sounds good. Please feel free to add > > Acked-by: Tejun Heo Done, thank you! Thanx, Paul From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Paul E. McKenney" Subject: Re: [PATCH] cgroup/cpuset: fix circular locking dependency Date: Tue, 9 Jan 2018 08:00:22 -0800 Message-ID: <20180109160022.GW9671@linux.vnet.ibm.com> References: <20180102174408.GM7829@linux.vnet.ibm.com> <20180102180119.GA1355@linux.vnet.ibm.com> <20180108122823.GL3668920@devbig577.frc2.facebook.com> <20180108225238.GN9671@linux.vnet.ibm.com> <20180109003127.GA30224@linux.vnet.ibm.com> <20180109034211.GC3668920@devbig577.frc2.facebook.com> <20180109042016.GR9671@linux.vnet.ibm.com> <20180109134448.GE3668920@devbig577.frc2.facebook.com> <20180109152112.GT9671@linux.vnet.ibm.com> <20180109153752.GI3668920@devbig577.frc2.facebook.com> Reply-To: paulmck-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8@public.gmane.org Mime-Version: 1.0 Return-path: Content-Disposition: inline In-Reply-To: <20180109153752.GI3668920-4dN5La/x3IkLX0oZNxdnEQ2O0Ztt9esIQQ4Iyu8u01E@public.gmane.org> Sender: cgroups-owner-u79uwXL29TY76Z2rM5mHXA@public.gmane.org List-ID: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: Tejun Heo Cc: Prateek Sood , Peter Zijlstra , avagin-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org, mingo-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org, linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, cgroups-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, sramana-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org On Tue, Jan 09, 2018 at 07:37:52AM -0800, Tejun Heo wrote: > Hello, Paul. > > On Tue, Jan 09, 2018 at 07:21:12AM -0800, Paul E. McKenney wrote: > > > The code was previously using both system_power_efficient_wq and > > > system_workqueue (for the expedited path). I guess the options were > > > either using two workqueues or dropping POWER_EFFICIENT. I have no > > > idea how big an impact this will make or whether it'd even be > > > noticeable but maybe it'd be worthwhile to mention that in the > > > description? > > > > Good point! How about if I change the last paragraph of the commit > > log to read as follows? > > > > Thanx, Paul > > > > ------------------------------------------------------------------------ > > > > This commit also causes SRCU to use this new RCU-specific > > workqueue_struct. Note that SRCU's use of workqueues never blocks them > > waiting for readers, so this should be safe from a forward-progress > > viewpoint. Note that this moves SRCU from system_power_efficient_wq > > to a normal workqueue. In the unlikely event that this results in > > measurable degradation, a separate power-efficient workqueue will be > > creates for SRCU. > > Sounds good. Please feel free to add > > Acked-by: Tejun Heo Done, thank you! Thanx, Paul