Messages in this thread | | | Date | Thu, 21 Feb 2002 16:15:49 +0100 (MET) | From | Erich Focht <> | Subject | Re: [PATCH] O(1) scheduler set_cpus_allowed for non-current tasks |
| |
Ingo,
thanks for the patch, I am glad to have an "official" solution! Though I'll wait for your 2.4.X patch to give it a try on Itanium SMP systems. But this lazy migration scheme looks nice and safe.
Best regards, Erich
On Thu, 21 Feb 2002, Ingo Molnar wrote:
> > On Thu, 21 Feb 2002, Erich Focht wrote: > > > well I whished this kind of feedback came at my first attempt to have > > a discussion on this subject. Would have saved me lots of reboots :-) > > i did not find out about the most fundamental problem until today, when i > tried to merge your patch. Much of Linux's development is trial & err, i > do that all the time as well. > > > The reaction those days was: > > > > Ingo> your patch does not solve the problem, the situation is more > > Ingo> complex. What happens if the target task is not 'current' and is > > Ingo> running on some other CPU? If we send the migration interrupt then > > Ingo> nothing guarantees that the task will reschedule anytime soon, so > > Ingo> the target CPU will keep spinning indefinitely. There are other > > Ingo> problems too, like crossing calls to set_cpus_allowed(), etc. Right > > Ingo> now set_cpus_allowed() can only be used for > > Ingo> the current task, and must be used by kernel code that knows what it > > Ingo> does. > > > > and later: > > > > Ingo> well, there is a way, by fixing the current mechanizm. But since > > Ingo> nothing uses it currently it wont get much testing. I only pointed > > Ingo> out that the patch does not solve some of the races. > > > > So I kept Ingo's design idea of sending IPIs. And I made it survive > > crossing calls and avoid spinning around for long time, specially in > > interrupt. > > the fundamental problem is with wait_task_inactive() called from IRQ > contexts - it can spin indefinitely. The above comments list some of the > other problems, and those can indeed be solved by extending the IPI > delivery mechanism, which you did. > > migration threads are a variation of the current scheduler as well -the > schedule()/wakeup() hotpath did not have to be touched. > > Ingo
- 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/
| |