Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756758AbYFCR5i (ORCPT ); Tue, 3 Jun 2008 13:57:38 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1753369AbYFCR5a (ORCPT ); Tue, 3 Jun 2008 13:57:30 -0400 Received: from wolverine02.qualcomm.com ([199.106.114.251]:20054 "EHLO wolverine02.qualcomm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752776AbYFCR53 (ORCPT ); Tue, 3 Jun 2008 13:57:29 -0400 X-IronPort-AV: E=McAfee;i="5200,2160,5309"; a="3470595" Message-ID: <48458604.3040804@qualcomm.com> Date: Tue, 03 Jun 2008 10:57:24 -0700 From: Max Krasnyanskiy User-Agent: Thunderbird 2.0.0.14 (X11/20080501) MIME-Version: 1.0 To: Dimitri Sivanich CC: Paul Jackson , linux-kernel@vger.kernel.org, Con Kolivas , "Derek L. Fults" , devik , Dinakar Guniguntala , Emmanuel Pacaud , Frederik Deweerdt , Ingo Molnar , Matthew Dobson , Nick Piggin , rostedt@goodmis.org, Oleg Nesterov , "Paul E. McKenney" , Paul Menage , Peter Zijlstra , "Randy.Dunlap" , suresh.b.siddha@intel.com, Thomas Gleixner Subject: Re: Inquiry: Should we remove "isolcpus= kernel boot option? (may have realtime uses) References: <20080601213019.14ea8ef8.pj@sgi.com> <20080602164203.GA2477@sgi.com> <48443E66.6060205@qualcomm.com> <20080602214151.GA7072@sgi.com> <48446D46.2010903@qualcomm.com> <20080603144010.GA25948@sgi.com> In-Reply-To: <20080603144010.GA25948@sgi.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1115 Lines: 25 Dimitri Sivanich wrote: > On Mon, Jun 02, 2008 at 02:59:34PM -0700, Max Krasnyansky wrote: >> Yes it used to be somewhat unstable. These days it solid. I'm using it on a >> wide range of systems: uTCA Core2Duo, NUMA dual-Opteron, 8way Core2, etc. And >> things work as expected. > > Max, > > I tried the following scenario on an ia64 Altix running 2.6.26-rc4 with > cpusets compiled in but cpuset fs unmounted. Do your patches already address this? Nope. My patch was a trivial fix for not destroying scheduler domains on hotplug events. The problem you're seeing is different. I'm not an expert in cpu hotplug internal machinery especially on ia64. Recent kernels (.22 and up) I've tried on x86 and x86-64 have no issues with cpu hotplug. You probably want to submit a bug report (in a separate thread) maybe it's a regression in the latest .26-rc series. Max -- 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/