From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751961AbcF0Odz (ORCPT ); Mon, 27 Jun 2016 10:33:55 -0400 Received: from mx2.suse.de ([195.135.220.15]:51793 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751655AbcF0Odx (ORCPT ); Mon, 27 Jun 2016 10:33:53 -0400 Date: Mon, 27 Jun 2016 16:33:50 +0200 From: Petr Mladek To: Tejun Heo Cc: Peter Zijlstra , Andrew Morton , Oleg Nesterov , Ingo Molnar , Steven Rostedt , "Paul E. McKenney" , Josh Triplett , Thomas Gleixner , Linus Torvalds , Jiri Kosina , Borislav Petkov , Michal Hocko , linux-mm@kvack.org, Vlastimil Babka , linux-api@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH v9 06/12] kthread: Add kthread_drain_worker() Message-ID: <20160627143350.GA3313@pathway.suse.cz> References: <1466075851-24013-1-git-send-email-pmladek@suse.com> <1466075851-24013-7-git-send-email-pmladek@suse.com> <20160622205445.GV30909@twins.programming.kicks-ass.net> <20160623213258.GO3262@mtj.duckdns.org> <20160624070515.GU30154@twins.programming.kicks-ass.net> <20160624155447.GY3262@mtj.duckdns.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20160624155447.GY3262@mtj.duckdns.org> 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 Hi, On Fri 2016-06-24 11:54:47, Tejun Heo wrote: > On Fri, Jun 24, 2016 at 09:05:15AM +0200, Peter Zijlstra wrote: > > > Given how rare that is > > > > Could you then not remove/rework these few cases for workqueue as well > > and make that 'better' too? > > Usage of draining is rare for workqueue but that still means several > legitimate users. With draining there, it's logical to use it during > shutdown. I don't think it makes sense to change it on workqueue > side. > > > > and the extra > > > complexity of identifying self-requeueing cases, let's forget about > > > draining and on destruction clear the worker pointer to block further > > > queueing and then flush whatever is in flight. > > > > You're talking about regular workqueues here? > > No, kthread worker. It's unlikely that kthread worker is gonna need > chained draining especially given that most of its usages are gonna be > conversions from raw kthread usages. We won't lose much if anything > by just ignoring draining and making the code simpler. OK, so you suggest to do the following: 1. Add a flag into struct kthread_worker that will prevent from further queuing. 2. kthread_create_worker()/kthread_destroy_worker() will not longer dynamically allocate struct kthread_worker. They will just start/stop the kthread. The result will be: a. User will not need the strict synchronization between the queue and create/destroy operations. b. We could get rid of drain_kthread_worker() because flush_kthread_worker() will be enough. IMHO, the 1st change does not make sense without the 2nd one. Otherwise, users could do an out-of-memory access when testing the freed kthread_worker flag. Do I get this correctly please? Best Regards, Petr