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

[Max Krasnyansky]

Linus Torvalds wrote:
> 
> On Sat, 12 Jul 2008, Linus Torvalds wrote:
>> This patch almost certainly doesn't work, but let me explain:
> 
> Well, I decided to just take the plunge and test it. It WorksForMe(tm), so 
> it's no _totally_ broken. But I really didn't test it except to see that 
> it still booted, and I don't use cpusets and never saw the original bug, 
> of course.
> 
> But considering how simple it is, if it works for people as a way to work 
> around stupid CPU migration issues due to subtle wakeup calls, I'd almost 
> prefer to really solve this whole issue with that cpu_active_map thing. 
> 
> It's so simple it should be really _robust_ in the presense of problems 
> elsewhere (like the whole cpusets scheduling domain mess).
> 
> Assuming I didn't do anythign stupid, of course, which is why it would 
> definitely need much more testing. And especially if Vegard can test it 
> with the case that oopsed for him due to the bad migration..

My vote goes for Dmitry's patch. The one with the full switch() statement.
Your simplified version with if() is correct (I think) but the switch() is
more explicit about what events are being processed.

The cpu_active_map thing seems like an overkill. In a sense that we should not
try to add a new map for every such case. Granter this migration case may be
special enough to warrant the new map but in general I think it's not the
right way to go.

btw Dmitry's patch should go in anyway. It makes no sense to kill and then
immediately rebuild domains during hotplug sequence.  Actually I might have a
bit better patch. I'm thinking we should just call rebuild_sched_domains() (or
some wrapper) from the sched hotplug handler. That way it'll be clear when
domains are supposed to be created/destroyed. ie We won't have to coordinate
cpu hotplug handling events between scheduler and cpusets. I'll send a patch a
bit later.

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/