From: Tejun Heo <tj@kernel.org>
To: Peter Zijlstra <peterz@infradead.org>
Cc: Petr Mladek <pmladek@suse.com>,
Andrew Morton <akpm@linux-foundation.org>,
Oleg Nesterov <oleg@redhat.com>, Ingo Molnar <mingo@redhat.com>,
Steven Rostedt <rostedt@goodmis.org>,
"Paul E. McKenney" <paulmck@linux.vnet.ibm.com>,
Josh Triplett <josh@joshtriplett.org>,
Thomas Gleixner <tglx@linutronix.de>,
Linus Torvalds <torvalds@linux-foundation.org>,
Jiri Kosina <jkosina@suse.cz>, Borislav Petkov <bp@suse.de>,
Michal Hocko <mhocko@suse.cz>,
linux-mm@kvack.org, Vlastimil Babka <vbabka@suse.cz>,
linux-api@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v9 06/12] kthread: Add kthread_drain_worker()
Date: Fri, 24 Jun 2016 11:54:47 -0400 [thread overview]
Message-ID: <20160624155447.GY3262@mtj.duckdns.org> (raw)
In-Reply-To: <20160624070515.GU30154@twins.programming.kicks-ass.net>
Hello,
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.
Thanks.
--
tejun
next prev parent reply other threads:[~2016-06-24 15:54 UTC|newest]
Thread overview: 33+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-06-16 11:17 [PATCH v9 00/12] kthread: Kthread worker API improvements Petr Mladek
2016-06-16 11:17 ` [PATCH v9 01/12] kthread: Rename probe_kthread_data() to kthread_probe_data() Petr Mladek
2016-06-20 19:16 ` Tejun Heo
2016-06-16 11:17 ` [PATCH v9 02/12] kthread: Kthread worker API cleanup Petr Mladek
2016-06-20 19:27 ` Tejun Heo
2016-06-16 11:17 ` [PATCH v9 03/12] kthread/smpboot: Do not park in kthread_create_on_cpu() Petr Mladek
2016-06-16 11:17 ` [PATCH v9 04/12] kthread: Allow to call __kthread_create_on_node() with va_list args Petr Mladek
2016-06-20 19:51 ` Tejun Heo
2016-06-16 11:17 ` [PATCH v9 05/12] kthread: Add kthread_create_worker*() Petr Mladek
2016-06-20 19:55 ` Tejun Heo
2016-06-16 11:17 ` [PATCH v9 06/12] kthread: Add kthread_drain_worker() Petr Mladek
2016-06-20 19:56 ` Tejun Heo
2016-06-22 20:54 ` Peter Zijlstra
2016-06-23 21:32 ` Tejun Heo
2016-06-24 7:05 ` Peter Zijlstra
2016-06-24 9:08 ` Petr Mladek
2016-06-24 15:54 ` Tejun Heo [this message]
2016-06-27 14:33 ` Petr Mladek
2016-06-28 17:04 ` Tejun Heo
2016-06-29 8:17 ` Petr Mladek
2016-06-29 13:15 ` Tejun Heo
2016-06-16 11:17 ` [PATCH v9 07/12] kthread: Add kthread_destroy_worker() Petr Mladek
2016-06-20 19:57 ` Tejun Heo
2016-06-16 11:17 ` [PATCH v9 08/12] kthread: Detect when a kthread work is used by more workers Petr Mladek
2016-06-20 20:10 ` Tejun Heo
2016-06-16 11:17 ` [PATCH v9 09/12] kthread: Initial support for delayed kthread work Petr Mladek
2016-06-20 20:20 ` Tejun Heo
2016-06-16 11:17 ` [PATCH v9 10/12] kthread: Allow to cancel " Petr Mladek
2016-06-20 20:27 ` Tejun Heo
2016-06-16 11:17 ` [PATCH v9 11/12] kthread: Allow to modify delayed " Petr Mladek
2016-06-20 20:29 ` Tejun Heo
2016-06-16 11:17 ` [PATCH v9 12/12] kthread: Better support freezable kthread workers Petr Mladek
2016-06-20 20:30 ` Tejun Heo
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20160624155447.GY3262@mtj.duckdns.org \
--to=tj@kernel.org \
--cc=akpm@linux-foundation.org \
--cc=bp@suse.de \
--cc=jkosina@suse.cz \
--cc=josh@joshtriplett.org \
--cc=linux-api@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mhocko@suse.cz \
--cc=mingo@redhat.com \
--cc=oleg@redhat.com \
--cc=paulmck@linux.vnet.ibm.com \
--cc=peterz@infradead.org \
--cc=pmladek@suse.com \
--cc=rostedt@goodmis.org \
--cc=tglx@linutronix.de \
--cc=torvalds@linux-foundation.org \
--cc=vbabka@suse.cz \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).