From: Tejun Heo <tj@kernel.org>
To: Lai Jiangshan <laijs@cn.fujitsu.com>
Cc: linux-kernel@vger.kernel.org
Subject: Re: [PATCH RFC] workqueue: don't grab PENDING bit on some conditions
Date: Tue, 15 Jul 2014 11:58:05 -0400 [thread overview]
Message-ID: <20140715155805.GD19570@htj.dyndns.org> (raw)
In-Reply-To: <1405416610-12394-1-git-send-email-laijs@cn.fujitsu.com>
Hello, Lai.
On Tue, Jul 15, 2014 at 05:30:10PM +0800, Lai Jiangshan wrote:
> Thread1 expects that, after flush_delayed_work() returns, the known pending
> work is guaranteed finished. But if Thread2 is scheduled a little later than
> Thread1, the known pending work is dequeued and re-queued, it is considered
> as two different works in the workqueue subsystem and the guarantee expected
They are two separate queueing instances of the same work item.
> by Thread1 is broken.
The guarantee expected by thread 1 is that the most recent queueing
instance of the work item is finished either through completing
execution or being cancelled. No guarantee is broken.
> The guarantee expected by Thread1/workqueue-user is reasonable for me,
> the workqueue subsystem should provide this guarantee. In another aspect,
You're adding a new component to the existing set of guarantees. You
can argue for it but it's a new guarantee regardless.
> the flush_delayed_work() is still working when mod_delayed_work_on() returns,
> it is more acceptable that the flush_delayed_work() beats the
> mod_delayed_work_on().
>
> It is achieved by introducing a KEEP_FLUSHED flag for try_to_grab_pending().
> If the work is being flushed and KEEP_FLUSHED flags is set,
> we disallow try_to_grab_pending() to grab the pending of the work.
>
> And there is another condition that the user want to speed up a delayed work.
>
> When the user use "mod_delayed_work_on(..., 0 /* zero delay */);", his
> attention is to accelerate the work and queue the work immediately.
>
> But the work does be slowed down when it is already queued on the worklist
> due to the work is dequeued and re-queued. So we also disallow
> try_to_grab_pending() to grab the pending of the work in this condition
> by introducing KEEP_QUEUED flag.
Both are extremely marginal. Do we have any actual cases any of these
matters? I can't see what we're gaining with the extra complexity.
> @@ -1212,6 +1220,13 @@ static int try_to_grab_pending(struct work_struct *work, bool is_dwork,
> */
> pwq = get_work_pwq(work);
> if (pwq && pwq->pool == pool) {
> + if ((keep_flags | KEEP_QUEUED) ||
> + ((keep_flags | KEEP_FLUSHED) &&
This can't be right.
Thanks.
--
tejun
next prev parent reply other threads:[~2014-07-15 15:58 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-07-15 9:30 [PATCH RFC] workqueue: don't grab PENDING bit on some conditions Lai Jiangshan
2014-07-15 15:58 ` Tejun Heo [this message]
2014-07-16 1:15 ` Lai Jiangshan
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=20140715155805.GD19570@htj.dyndns.org \
--to=tj@kernel.org \
--cc=laijs@cn.fujitsu.com \
--cc=linux-kernel@vger.kernel.org \
/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