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
| ||
|
Date: Thu, 22 Mar 2012 15:49:20 -0700 From: "Paul E. McKenney" <paulmck@...ux.vnet.ibm.com> To: Rusty Russell <rusty@...tcorp.com.au> Cc: Peter Zijlstra <a.p.zijlstra@...llo.nl>, "Srivatsa S. Bhat" <srivatsa.bhat@...ux.vnet.ibm.com>, Arjan van de Ven <arjan@...radead.org>, Steven Rostedt <rostedt@...dmis.org>, "Rafael J. Wysocki" <rjw@...k.pl>, Srivatsa Vaddagiri <vatsa@...ux.vnet.ibm.com>, "akpm@...ux-foundation.org" <akpm@...ux-foundation.org>, Paul Gortmaker <paul.gortmaker@...driver.com>, Milton Miller <miltonm@....com>, "mingo@...e.hu" <mingo@...e.hu>, Tejun Heo <tj@...nel.org>, KOSAKI Motohiro <kosaki.motohiro@...il.com>, linux-kernel <linux-kernel@...r.kernel.org>, Linux PM mailing list <linux-pm@...r.kernel.org> Subject: Re: CPU Hotplug rework On Thu, Mar 22, 2012 at 02:55:04PM +1030, Rusty Russell wrote: > On Wed, 21 Mar 2012 10:01:59 +0100, Peter Zijlstra <a.p.zijlstra@...llo.nl> wrote: > > On Wed, 2012-03-21 at 09:30 +1030, Rusty Russell wrote: > > > > > (2) Do something more efficient with userspace threads than migrating > > > > > them one at a time. > > > > > > > > Sadly that can't really be done. We need to pick up every task > > > > (userspace, but also running kernel threads) and update their state. > > > > > > What if we had an "orphan" runqueue which everyone pulled from? Then we > > > could grab the lock, move them all to the fake rq, then let stuff happen > > > normally. > > > > Well, we could simply let them sit where they are and fudge load-balance > > to consider it a source but not a destination until its empty, but it > > might be somewhat tricky to make it fast enough to not introduce > > noticable latencies. Also, you really don't want everyone to pull, > > that's a serialization/scalability problem. > > > > Also, since we really only move the currently runnable tasks it > > shouldn't be too many in the first place. Is it really that expensive? > > Good question, requires measurement to answer. > > > > Maybe that's crap, but at least we could move the migration out of the > > > hotplug callback somehow. > > > > Thing is, if its really too much for some people, they can orchestrate > > it such that its not. Just move everybody in a cpuset, clear the to be > > offlined cpu from the cpuset's mask -- this will migrate everybody away. > > Then hotplug will find an empty runqueue and its fast, no? > > I like this solution better. As long as we have some way to handle kthreads that are algorithmically tied to a given CPU. There are coding conventions to handle this, for example, do everything with preemption disabled and just after each preempt_disable() verify that you are in fact running on the correct CPU, but it is easy to imagine improvements. Thanx, Paul -- 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/
Powered by blists - more mailing lists