Re: current linux-2.6.git: cpusets completely broken

[Max Krasnyansky]

Dmitry Adamushko wrote:
> 2008/7/15 Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx>:
>>
>> On Tue, 15 Jul 2008, Dmitry Adamushko wrote:
>>> The 'synchronization' point occurs even earlier - when cpu_down() ->
>>> __stop_machine_run() gets called (as I described in my previous mail).
>>>
>>> My point was that if it's ok to have a _delayed_ synchronization
>>> point, having it not immediately after cpu_clear(cpu, cpu_active_map)
>>> but when the "runqueue lock" is taken a bit later (as you pointed out
>>> above) or __stop_machine_run() gets executed (which is a sync point,
>>> scheduling-wise),
>>>
>>> then we can implement the proper synchronization (hotplugging vs.
>>> task-migration) with cpu_online_map (no need for cpu_active_map).
>> [ ... ]
>>
>> In particular, it should tell you that the code is too hard to follow, and
>> too fragile, and a total mess.
>>
>> I do NOT understand why you seem to argue for being "subtle" and "clever",
>> considering the history of this whole setup. Subtle and clever and complex
>> is what got us to the crap situation.
> 
> Fair enough, agreed.

Ok. Sounds like the consensus is to try and do this cpu_active_map thing, and
it sounds like it will lets us get rid of the "destroy domains / rebuild
domains" logic, which would be a good thing. I've spent a good part of the
weekend chasing circular locking dependencies in calling
rebuild_sched_domains() from cpu hotplug handler path. Which we'll still need
(to update domains on CPU UP and DOWN events) but not having to blow away the
domains as often as we do now will simplify things, and probably make hotplug
events a bit less disruptive.

Did you guys an updated patch ? Dmitry pointed out several things that Linus
missed in his original version. I guess I can go through the thread and
reconstruct that but if you have a patch I can try let me know.

Max
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/