From mboxrd@z Thu Jan 1 00:00:00 1970 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1757157AbeAHM23 (ORCPT + 1 other); Mon, 8 Jan 2018 07:28:29 -0500 Received: from mail-qk0-f181.google.com ([209.85.220.181]:42286 "EHLO mail-qk0-f181.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1756544AbeAHM21 (ORCPT ); Mon, 8 Jan 2018 07:28:27 -0500 X-Google-Smtp-Source: ACJfBot8U0Q0skyJMm7DqYkdUL39OlzxQtEgKr8TjQ3SwLcsxXq82a6WqZPc5d9PAGE1Dnf9UfEA4g== Date: Mon, 8 Jan 2018 04:28:23 -0800 From: Tejun Heo To: "Paul E. McKenney" 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 Message-ID: <20180108122823.GL3668920@devbig577.frc2.facebook.com> References: <20171204202219.GF2421075@devbig577.frc2.facebook.com> <20171204225825.GP2421075@devbig577.frc2.facebook.com> <20171204230117.GF20227@worktop.programming.kicks-ass.net> <20171211152059.GH2421075@devbig577.frc2.facebook.com> <20171213160617.GQ3919388@devbig577.frc2.facebook.com> <9843d982-d201-8702-2e4e-0541a4d96b53@codeaurora.org> <20180102161656.GD3668920@devbig577.frc2.facebook.com> <20180102174408.GM7829@linux.vnet.ibm.com> <20180102180119.GA1355@linux.vnet.ibm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20180102180119.GA1355@linux.vnet.ibm.com> User-Agent: Mutt/1.5.21 (2010-09-15) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Return-Path: Hello, Paul. Sorry about the delay. Travel followed by cold. :( On Tue, Jan 02, 2018 at 10:01:19AM -0800, Paul E. McKenney wrote: > Actually, after taking a quick look, could you please supply me with > a way of mark a statically allocated workqueue as WQ_MEM_RECLAIM after > the fact? Otherwise, I end up having to check for the workqueue having Hmmm... there is no statically allocated workqueue tho. If you're referring to the system-wide workqueues (system*_wq), they're just created dynamically early during boot. > been allocated pretty much each time I use it, which is going to be an > open invitation for bugs. Plus it looks like there are ways that RCU's > workqueue wakeups can be executed during very early boot, which can be > handled, but again in a rather messy fashion. > > In contrast, given a way of mark a statically allocated workqueue > as WQ_MEM_RECLAIM after the fact, I simply continue initializing the > workqueue at early boot, and then add the WQ_MEM_RECLAIM marking some > arbitrarily chosen time after the scheduler has been initialized. > > The required change to workqueues looks easy, just move the body of > the "if (flags & WQ_MEM_RECLAIM) {" statement in __alloc_workqueue_key() > to a separate function, right? Ah, okay, yes, currently, workqueue init is kinda silly in that while it allows init of non-mem-reclaiming workqueues way before workqueue is actually online, it doesn't allow the same for mem-reclaiming ones. As you pointed out, it's just an oversight on my part as the init path split was done initially to accomodate early init of system workqueues. I'll update the code so that rescuers can be added later too; however, please note that while the work items may be queued, they won't be executed until workqueue_init() is run (the same as now) as there can't be worker threads anyway before that point. Thanks. -- tejun From mboxrd@z Thu Jan 1 00:00:00 1970 From: Tejun Heo Subject: Re: [PATCH] cgroup/cpuset: fix circular locking dependency Date: Mon, 8 Jan 2018 04:28:23 -0800 Message-ID: <20180108122823.GL3668920@devbig577.frc2.facebook.com> References: <20171204202219.GF2421075@devbig577.frc2.facebook.com> <20171204225825.GP2421075@devbig577.frc2.facebook.com> <20171204230117.GF20227@worktop.programming.kicks-ass.net> <20171211152059.GH2421075@devbig577.frc2.facebook.com> <20171213160617.GQ3919388@devbig577.frc2.facebook.com> <9843d982-d201-8702-2e4e-0541a4d96b53@codeaurora.org> <20180102161656.GD3668920@devbig577.frc2.facebook.com> <20180102174408.GM7829@linux.vnet.ibm.com> <20180102180119.GA1355@linux.vnet.ibm.com> Mime-Version: 1.0 Return-path: DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=vPAmv7XATBHrbN7x6IXaYnCYCeaFVF3b1RhaSLFIUFI=; b=NYsuBShw4WkM0QkR02WBvTcJIutUqDArQK35UXsTo0rD/OVBPfeSuVRpcKT4RyD4td oJEWKQdceTANty73yjBB70KIO089HCccAfaEUMGUnmyjRxYaF+36MsDze+4kr0faTxS2 w95kjxIcPjA3yrdkoxNhSHnl6CYIuFvu798B6xj+xf7nJ1uZR6J6wYSM7S2xepl7CIjC lBjTNBCcWep5UEHlxoFWxO2X6xhdi1VvOVo3WX/2gd05/HttZsOqqzc7LYde0ys+pmWk OKzdOpfmrZmJaqUT4ue1dcnZS2p4y9zqYVrCMsfawzuGvPJ/kqXU+IbrfhtsFE3PlJ67 fwvg== Content-Disposition: inline In-Reply-To: <20180102180119.GA1355-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8@public.gmane.org> Sender: cgroups-owner-u79uwXL29TY76Z2rM5mHXA@public.gmane.org List-ID: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: "Paul E. McKenney" 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 Hello, Paul. Sorry about the delay. Travel followed by cold. :( On Tue, Jan 02, 2018 at 10:01:19AM -0800, Paul E. McKenney wrote: > Actually, after taking a quick look, could you please supply me with > a way of mark a statically allocated workqueue as WQ_MEM_RECLAIM after > the fact? Otherwise, I end up having to check for the workqueue having Hmmm... there is no statically allocated workqueue tho. If you're referring to the system-wide workqueues (system*_wq), they're just created dynamically early during boot. > been allocated pretty much each time I use it, which is going to be an > open invitation for bugs. Plus it looks like there are ways that RCU's > workqueue wakeups can be executed during very early boot, which can be > handled, but again in a rather messy fashion. > > In contrast, given a way of mark a statically allocated workqueue > as WQ_MEM_RECLAIM after the fact, I simply continue initializing the > workqueue at early boot, and then add the WQ_MEM_RECLAIM marking some > arbitrarily chosen time after the scheduler has been initialized. > > The required change to workqueues looks easy, just move the body of > the "if (flags & WQ_MEM_RECLAIM) {" statement in __alloc_workqueue_key() > to a separate function, right? Ah, okay, yes, currently, workqueue init is kinda silly in that while it allows init of non-mem-reclaiming workqueues way before workqueue is actually online, it doesn't allow the same for mem-reclaiming ones. As you pointed out, it's just an oversight on my part as the init path split was done initially to accomodate early init of system workqueues. I'll update the code so that rescuers can be added later too; however, please note that while the work items may be queued, they won't be executed until workqueue_init() is run (the same as now) as there can't be worker threads anyway before that point. Thanks. -- tejun