linux-kernel - Re: [PATCH 4/7] sched: implement force_cpus

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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <4B1E3EE0.7030001@kernel.org>
Date:	Tue, 08 Dec 2009 20:56:16 +0900
From:	Tejun Heo <tj@...nel.org>
To:	Peter Zijlstra <peterz@...radead.org>
CC:	tglx@...utronix.de, mingo@...e.hu, avi@...hat.com, efault@....de,
	rusty@...tcorp.com.au, linux-kernel@...r.kernel.org,
	Gautham R Shenoy <ego@...ibm.com>,
	Linus Torvalds <torvalds@...ux-foundation.org>
Subject: Re: [PATCH 4/7] sched: implement force_cpus_allowed()

Hello,

On 12/08/2009 08:48 PM, Peter Zijlstra wrote:
> Why bother with that?
> 
> workqueue's CPU_POST_DEAD will flush the workqueue and destroy all
> threads under cpu_add_remove_lock, which excludes the cpu from coming
> back up before its fully destroyed.
> 
> So there's no remaining tasks to be migrated back.
> 
> Changing that semantics is not worthwhile.

It is worthwhile because the goal is to unify all worker pool
mechanisms.  So, slow_work or whatnot (scsi EHs, FS specific worker
pools, async workers used for parallel probing) will all be converted
to use workqueue instead and with that we can't afford to wait for all
works to flush to down a cpu.  All that's necessary to implement that
is migrating back the unbound workers which can be implemented as a
separate piece of code apart from regular operation.  It would even
benefit the current implementation as it makes cpu up/down operations
much more deterministic.

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/