On Mon, 14 Jul 2008, Steven Rostedt wrote:

quoted text
> 
> 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?

		Linus
--
unsubscribe notice
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/