public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
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

  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