From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wi0-f178.google.com (mail-wi0-f178.google.com [209.85.212.178]) by kanga.kvack.org (Postfix) with ESMTP id 149F56B0257 for ; Mon, 5 Oct 2015 07:09:29 -0400 (EDT) Received: by wiclk2 with SMTP id lk2so109175594wic.1 for ; Mon, 05 Oct 2015 04:09:28 -0700 (PDT) Received: from mx2.suse.de (mx2.suse.de. [195.135.220.15]) by mx.google.com with ESMTPS id k6si15767220wiw.1.2015.10.05.04.09.27 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 05 Oct 2015 04:09:27 -0700 (PDT) Date: Mon, 5 Oct 2015 13:09:24 +0200 From: Petr Mladek Subject: Re: [RFC v2 07/18] kthread: Allow to cancel kthread work Message-ID: <20151005110924.GL9603@pathway.suse.cz> References: <1442840639-6963-1-git-send-email-pmladek@suse.com> <1442840639-6963-8-git-send-email-pmladek@suse.com> <20150922193513.GE17659@mtj.duckdns.org> <20150925112617.GA3122@pathway.suse.cz> <20150928170314.GF2589@mtj.duckdns.org> <20151002154336.GC3122@pathway.suse.cz> <20151002192453.GA7564@mtj.duckdns.org> <20151005100758.GK9603@pathway.suse.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20151005100758.GK9603@pathway.suse.cz> Sender: owner-linux-mm@kvack.org List-ID: To: Tejun Heo Cc: Andrew Morton , Oleg Nesterov , Ingo Molnar , Peter Zijlstra , Steven Rostedt , "Paul E. McKenney" , Josh Triplett , Thomas Gleixner , Linus Torvalds , Jiri Kosina , Borislav Petkov , Michal Hocko , linux-mm@kvack.org, Vlastimil Babka , live-patching@vger.kernel.org, linux-api@vger.kernel.org, linux-kernel@vger.kernel.org On Mon 2015-10-05 12:07:58, Petr Mladek wrote: > On Fri 2015-10-02 15:24:53, Tejun Heo wrote: > > Hello, > > > > On Fri, Oct 02, 2015 at 05:43:36PM +0200, Petr Mladek wrote: > > > IMHO, we need both locks. The worker manipulates more works and > > > need its own lock. We need work-specific lock because the work > > > might be assigned to different workers and we need to be sure > > > that the operations are really serialized, e.g. queuing. > > > > I don't think we need per-work lock. Do we have such usage in kernel > > at all? If you're worried, let the first queueing record the worker > > and trigger warning if someone tries to queue it anywhere else. This > > doesn't need to be full-on general like workqueue. Let's make > > reasonable trade-offs where possible. > > I actually thought about this simplification as well. But then I am > in doubts about the API. It would make sense to assign the worker > when the work is being initialized and avoid the duplicate information > when the work is being queued: > > init_kthread_work(work, fn, worker); > queue_work(work); > > Or would you prefer to keep the API similar to workqueues even when > it makes less sense here? > > > In each case, we need a way to switch the worker if the old one > is destroyed and a new one is started later. We would need > something like: > > reset_work(work, worker) > or > reinit_work(work, fn, worker) I was too fast. We could set "work->worker = NULL" when the work finishes and it is not pending. It means that it will be connected to the particular worker only when used. Then we could keep the workqueues-like API and do not need reset_work(). I am going to play with this. I feel that it might work. Best Regards, Petr -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: email@kvack.org