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: <1260344486.5489.38.camel@laptop>
Date:	Wed, 09 Dec 2009 08:41:26 +0100
From:	Peter Zijlstra <peterz@...radead.org>
To:	Tejun Heo <tj@...nel.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()

On Wed, 2009-12-09 at 14:25 +0900, Tejun Heo wrote:
> As for the force_cpus_allowed() bit, I think it's a rather natural
> interface to have and maybe we can replace kthread_bind() with it or
> make kthread_bind() in terms of it.  It's the basic migration function
> which adheres to the cpu hot plug/unplug synchronization rules.

I quite disagree, its quite unnatural to be adding threads to a cpu that
is about to go down or about to come up for that matter, and we most
certainly don't want to add to the hotplug rules, there are quite enough
of them already.

You could always do it from CPU_ONLINE, since they don't care about
cpu-affinity anyway (the thing was down for crying out loud), it really
doesn't matter when they're moved back if at all.

I still think its utter insanity to even consider moving them back, or
for that matter to have worklets that take minutes to complete, that's
just daft.

I think I'm going to NAK all this, it looks quite ill conceived.

--
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/