All of lore.kernel.org
 help / color / mirror / Atom feed
From: Lai Jiangshan <laijs@cn.fujitsu.com>
To: Tejun Heo <tj@kernel.org>
Cc: linux-kernel@vger.kernel.org
Subject: Re: [PATCH] workqueue: clear workers of a pool after the CPU is offline
Date: Fri, 26 Jul 2013 10:13:25 +0800	[thread overview]
Message-ID: <51F1DB45.90905@cn.fujitsu.com> (raw)
In-Reply-To: <20130725153121.GF26107@mtj.dyndns.org>

On 07/25/2013 11:31 PM, Tejun Heo wrote:
> Hello, Lai.
> 
> On Thu, Jul 25, 2013 at 06:52:02PM +0800, Lai Jiangshan wrote:
>> The unbound pools and their workers can be destroyed/cleared
>> when their refcnt become zero. But the cpu pool can't be destroyed
>> due to they are always referenced, their refcnt are always > 0.
>>
>> We don't want to destroy the cpu pools, but we want to destroy
>> the workers of the pool when the pool is full idle after the cpu
>> is offline. This is the default behavior in old days until
>> we removed the trustee_thread().
>>
>> We need to find a new way to restore this behavior,
>> We add offline_pool() and POOL_OFFLINE flag to do so.
> 
> Hmmm... if I'm not confused, now the cpu pools just behave like a
> normal unbound pool when the cpu goes down,

cpu pools are always referenced, they don't behave like unbound pool.

> which means that the idle
> cpu workers will exit once idle timeout is reached, right? 

No, no code to force the cpu workers quit currently.
you can just offline a cpu to see what happened to the workers.

> I really
> don't think it'd be worthwhile to add extra logic to accelerate the
> process.
> 
> Note that there actually are benefits to doing it asynchronously as
> CPUs go up and down very frequently on mobile platforms and destroying
> idle workers as soon as possible would just mean that we'd be doing a
> lot of work which isn't necessary.  I mean, we even grew an explicit
> mechanism to park kthreads to avoid repeatedly creating and destroying
> per-cpu kthreads as cpus go up and down.  I don't see any point in
> adding code to go the other direction.
> 
> Thanks.
> 


  reply	other threads:[~2013-07-26  2:09 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-07-25 10:52 [PATCH] workqueue: clear workers of a pool after the CPU is offline Lai Jiangshan
2013-07-25 15:31 ` Tejun Heo
2013-07-26  2:13   ` Lai Jiangshan [this message]
2013-07-26  3:07     ` Tejun Heo
2013-07-26  3:47       ` Lai Jiangshan
2013-07-26 10:22         ` Tejun Heo
2013-07-26 16:55           ` Lai Jiangshan
2013-07-26 17:03             ` Tejun Heo
  -- strict thread matches above, loose matches on Subject: below --
2013-02-20 17:04 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=51F1DB45.90905@cn.fujitsu.com \
    --to=laijs@cn.fujitsu.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=tj@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.