Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1758011AbYGODrh (ORCPT ); Mon, 14 Jul 2008 23:47:37 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1753921AbYGODr3 (ORCPT ); Mon, 14 Jul 2008 23:47:29 -0400 Received: from hrndva-omtalb.mail.rr.com ([71.74.56.123]:37198 "EHLO hrndva-omtalb.mail.rr.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753701AbYGODr3 (ORCPT ); Mon, 14 Jul 2008 23:47:29 -0400 Date: Mon, 14 Jul 2008 23:47:27 -0400 (EDT) From: Steven Rostedt X-X-Sender: rostedt@gandalf.stny.rr.com To: Linus Torvalds cc: Dmitry Adamushko , Vegard Nossum , Paul Menage , Max Krasnyansky , Paul Jackson , Peter Zijlstra , miaox@cn.fujitsu.com, Thomas Gleixner , Ingo Molnar , Linux Kernel Subject: Re: current linux-2.6.git: cpusets completely broken In-Reply-To: Message-ID: References: <20080712031736.GA3040@damson.getinternet.no> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2254 Lines: 51 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 -- 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/