All of lore.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 1/2 V3] workqueue: substitute POOL_FREEZING with __WQ_FREEZING
Date: Mon, 21 Apr 2014 18:20:35 -0400	[thread overview]
Message-ID: <20140421222035.GA22730@htj.dyndns.org> (raw)
In-Reply-To: <1398081561-12618-1-git-send-email-laijs@cn.fujitsu.com>

On Mon, Apr 21, 2014 at 07:59:20PM +0800, Lai Jiangshan wrote:
> Only workqueues have freezable or freezing attribution/state, not worker pools.
> But POOL_FREEZING adds a suspicious state and makes reviewers confused.
> 
> And it causes freeze_workqueues_begin() and thaw_workqueues() much complicated,
> they need to travel all the pools besides wqs.
> 
> Since freezable is workqueue instance's attribution, and freezing
> is workqueue instance's state, so we introduce __WQ_FREEZING
> to wq->flags instead and remove POOL_FREEZING.
> 
> It is different from POOL_FREEZING, POOL_FREEZING is simply set
> all over the world(all pools), while __WQ_FREEZING is only set for freezable wq.
> freeze_workqueues_begin()/thaw_workqueues() skip to handle non-freezable wqs
> and don't touch the non-freezable wqs' flags.

I was about to apply the patch and have updated the patch description.

  While freezing takes place globally, its execution is per-workqueue;
  however, the current implementation makes use of the per-worker_pool
  POOL_FREEZING flag.  While it's not broken, the flag makes the code
  more confusing and complicates freeze_workqueues_begin() and
  thaw_workqueues() by requiring them to walk through all pools.

  Since freezable is a workqueue's attribute, and freezing is a
  workqueue's state, let's introduce __WQ_FREEZING to wq->flags instead
  and remove POOL_FREEZING.

  It is different from POOL_FREEZING in that __WQ_FREEZING is only set
  for freezable workqueues while POOL_FREEZING is set globally over all
  pools.  freeze_workqueues_begin() and thaw_workqueues() now skip
  non-freezable workqueues.

But looking at the patch, why do we need __WQ_FREEZING at all?  We
should be able to test workqueue_freezing in pwq_adjust_max_active(),
right?  The only requirement there would be that
pwq_adjust_max_active(0 is invoked at least once after
workqueue_freezing is changed, which is already guaranteed.

Thanks.

-- 
tejun

  parent reply	other threads:[~2014-04-21 22:20 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-04-21 11:59 [PATCH 1/2 V3] workqueue: substitute POOL_FREEZING with __WQ_FREEZING Lai Jiangshan
2014-04-21 11:59 ` [PATCH 2/2 V3] workqueue: simple refactor pwq_adjust_max_active() Lai Jiangshan
2014-04-21 22:20 ` Tejun Heo [this message]
2014-04-22  1:47   ` [PATCH 1/2 V3] workqueue: substitute POOL_FREEZING with __WQ_FREEZING Lai Jiangshan
2014-04-22 20:46     ` Tejun Heo
2014-04-23  1:37       ` 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=20140421222035.GA22730@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.