Messages in this thread | | | Date | Tue, 6 Apr 2004 20:50:46 +0530 | From | Srivatsa Vaddagiri <> | Subject | Re: [Experimental CPU Hotplug PATCH] - Move migrate_all_tasks to CPU_DEAD handling |
| |
On Wed, Apr 07, 2004 at 01:04:10AM +1000, Nick Piggin wrote: > AFAIKS, no. > > If this happens before migrate_all_tasks, there shouldn't be a > problem because migrate_all_tasks will move the woken task anyway. > > It can't happen after migrate_all_tasks, because there is nothing > on the offline CPU to be woken up.
Hmm ..I was thinking of this scenario ..Lets say task A uses schedule_timeout on CPU3 :
schedule_timeout(10ms);
A timer is added in CPU3 meant to fire after (max) 10 ms. The task is then put to sleep.
During this sleep duration, CPU3 can go down. migrate_all_tasks not finding A in the runqueue won't bother abt it.
As pary of CPU_DEAD processing, migrate_timers will move the timer that was added in CPU3 to CPU2 (say).
After 10 ms, when the timer fires on CPU2, it will do a wakeup on Task A. At that point, won't Task A still be affine to CPU3? Won't try_to_wake_up attempt adding it to CPU3? At that point 'this_cpu' is 2 and 'cpu' is 3 (in try_to_wake_up)?
> If you do need the check there, then my lazy migrate method is > unquestionably better, because this is the only thing it would > otherwise have to add to a fastpath. Right?
I don't think we strictly need the cpu_is_offline check in try_to_wake_up if we were to migrate _all_ (running 'n sleeping) tasks in one shot (with tasklist lock held) when a CPU goes down :-)
Sorry I did not mean to compare our patches like this, just trying to work out which will be the right thing to do!!
--
Thanks and Regards, Srivatsa Vaddagiri, Linux Technology Center, IBM Software Labs, Bangalore, INDIA - 560017 - 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/
| |