linux-kernel - Re: [PATCH] workqueue: clear workers of a pool after the CPU is offline

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Thu, 25 Jul 2013 11:31:21 -0400
From:	Tejun Heo <tj@...nel.org>
To:	Lai Jiangshan <laijs@...fujitsu.com>
Cc:	linux-kernel@...r.kernel.org
Subject: Re: [PATCH] workqueue: clear workers of a pool after the CPU is
 offline

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, which means that the idle
cpu workers will exit once idle timeout is reached, right?  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.

-- 
tejun
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/