![]() | |||||||||||
Messages in this thread |
On Mon, Apr 02, 2007 at 08:56:07PM +0200, Ingo Molnar wrote: > ok. But the only real problem would be for_each_online_cpu() loops that > might sleep, correct? I would shy from saying that "that's the only problem". It could also be for_each_cpu_mask(some_mask) do_something_which_sleeps(); where some_mask is suppsoed to represent a subset of online cpus. For ex: policy->cpus is a mask maintained by cpufreq, which it iterates thr' whenever changing cpu frequency. The cpus in that mask are supposed to be a subset of online cpus (with CPU_ONLINE/DEAD handlers in cpufreq.c adjusting the mask upon hotplug). We could adopt a similar trick (get/put_each_cpu_mask) that you describe below in those extended cases as well. > the 10% loops that _can_ schedule would trigger the __might_sleep() > atomicity test in schedule()), and those would have to be converted a > bit more cleverly, on a case by case basis. The real question is how do we convert over those sleeping for_each_cpu_mask users (for ex: flush_workqueue) such that they don't block freezer/hotplug for long periods? One option is to probably rewrite them to understand that online[or a derived]_map could have changed everytime they come out of a (un)interruptible sleep and deal with arising races appropriately. That would mean a bit of maintenance headache unfortunately (I was hoping freezer will lead to zero maintenance headache :) Besides, how problematic is this in practise (that threads sleep for extended durations in TASK_INTERRUPTIBLE state breaking freezer/suspend/hotplug)? Should we ignore this for the timebeing and take up later as and when users report problems? -- Regards, vatsa - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ | ||||||||||
| Last update: 2007-04-03 14:51 [from the cache] ©2003-2008 | |||||||||||