Messages in this thread | | | Date | Mon, 14 Jul 2008 23:47:27 -0400 (EDT) | From | Steven Rostedt <> | Subject | Re: current linux-2.6.git: cpusets completely broken |
| |
On Mon, 14 Jul 2008, Linus Torvalds wrote: > > > > On Mon, 14 Jul 2008, Linus Torvalds wrote: > > > So by doing the test for cpu_active_map not at queuing time, but at the > > > time when we actually try to do the migration, we can now also make that > > > cpu_active_map be totally serialized. > > > > > > (Of course, anybody who clears the bit does need to take the runqueue lock > > > of that CPU too, but cpu_down() will have to do that as it does the > > > "migrate away live tasks" anyway, so that's not a problem) > > > > Wouldn't simply doing a synchronize_sched() after clearing the bit also > > make sure that no new task will be scheduled on that CPU? > > My point was that it DOESN'T NEED TO DO ANYTHING AT ALL. > > It has to get the runqueue lock in order to move the currently executing > threads off that CPU anyway. The fact that it can (and actually does) > synchronize with the scheduler in other ways is totally and utterly > immaterial. > > That's what "robust" means. It means that things just work, and there are > no subtle interactions. > > Sure, you can serialize with something complicated and heavy. > > But isn't it nice that the absolutely _least_ complicated and heavy > operation (ie getting the runqueue lock) also serializes sufficiently? > Isn't it nice how you have to do that in order to do all those other > things that you obviously have to do? > > Please don't argue about how we can add more subtle rules, or how other > thigns can serialize this thing as well. Isn't it sufficient that the > _obvious_ things serialize it?
Oh, I'm not arguing. My mind is going off to an even bigger picture, where something in the future would need to stop migration to a particular CPU, and that it could simply clear the bit and call synchronize_sched. The run queue lock is only visible to the scheduler. Sorry, I may have been day dreaming out loud ;-)
But for the case at hand, yes I agree, simply grabbing the run queue lock is a very elegant and simple solution.
-- Steve
| |