Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755381AbYGMSTp (ORCPT ); Sun, 13 Jul 2008 14:19:45 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1753427AbYGMSTi (ORCPT ); Sun, 13 Jul 2008 14:19:38 -0400 Received: from mx3.mail.elte.hu ([157.181.1.138]:41648 "EHLO mx3.mail.elte.hu" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752960AbYGMSTh (ORCPT ); Sun, 13 Jul 2008 14:19:37 -0400 Date: Sun, 13 Jul 2008 20:19:10 +0200 From: Ingo Molnar To: Dmitry Adamushko Cc: Linus Torvalds , Vegard Nossum , Paul Menage , Max Krasnyansky , Paul Jackson , Peter Zijlstra , miaox@cn.fujitsu.com, rostedt@goodmis.org, Thomas Gleixner , Linux Kernel Subject: Re: current linux-2.6.git: cpusets completely broken Message-ID: <20080713181910.GA22052@elte.hu> References: <19f34abd0807121600l653e28bfwb5cce2d880b7f2cd@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.18 (2008-05-17) X-ELTE-VirusStatus: clean X-ELTE-SpamScore: -1.5 X-ELTE-SpamLevel: X-ELTE-SpamCheck: no X-ELTE-SpamVersion: ELTE 2.0 X-ELTE-SpamCheck-Details: score=-1.5 required=5.9 tests=BAYES_00 autolearn=no SpamAssassin version=3.2.3 -1.5 BAYES_00 BODY: Bayesian spam probability is 0 to 1% [score: 0.0000] Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2100 Lines: 54 * Dmitry Adamushko wrote: > > So instead of this illogical and crazy mess: > > > > + switch (phase) { > > + case CPU_UP_CANCELED: > > + case CPU_UP_CANCELED_FROZEN: > > + case CPU_DOWN_FAILED: > > + case CPU_DOWN_FAILED_FROZEN: > > + case CPU_ONLINE: > > + case CPU_ONLINE_FROZEN: > > + case CPU_DEAD: > > + case CPU_DEAD_FROZEN: > > + common_cpu_mem_hotplug_unplug(1); > > > > it should just say > > > > + switch (phase) { > > + case CPU_ONLINE: > > + case CPU_ONLINE_FROZEN: > > + case CPU_DEAD: > > + case CPU_DEAD_FROZEN: > > + common_cpu_mem_hotplug_unplug(1); > > > > because it only makes sense to rebuild the scheduler domains when the > > thing SUCCEEDS. > > > > See? By having a sane design, the code is not just more robust and > > easy to follow, you can also simplify it and make it more logical. > > Yes, I agree. And I did _not_ say that the current design is sane. My > impression about changes acceptable during a late release cycle was > utterly CRAPPY (indeed, it's always better to immediately fix a > problem the right way, not just add another patch and pray it doesn't > break somewhere else). mind sending Linus's patch as a completed patchset against tip/master (or tip/sched/devel) so that we can do it in early v2.6.27? i still think your cpusets.c fix is what we should do for v2.6.26, given that there's agreement about how to fix it for real and thus in terms of regression/bug risk your patch is lower-impact and CPU hotplug has been broken for such a long time. But we should follow it up with Linus's patch immediately afterwards in v2.6.27. Hm? Ingo -- 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/