Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id ; Mon, 10 Jun 2002 03:00:50 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Mon, 10 Jun 2002 03:00:49 -0400 Received: from [202.135.142.196] ([202.135.142.196]:29193 "EHLO wagner.rustcorp.com.au") by vger.kernel.org with ESMTP id ; Mon, 10 Jun 2002 03:00:49 -0400 From: Rusty Russell To: ebiederm@xmission.com (Eric W. Biederman) Cc: linux-kernel@vger.kernel.org, ralf@gnu.org, rhw@memalpha.cx, mingo@redhat.com, paulus@samba.org, anton@samba.org, schwidefsky@de.ibm.com, bh@sgi.com, davem@redhat.com, ak@suse.de, torvalds@transmeta.com Subject: Re: Hotplug CPU Boot Changes: BEWARE In-Reply-To: Your message of "07 Jun 2002 08:51:32 CST." Date: Mon, 10 Jun 2002 17:05:16 +1000 Message-Id: Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org In message you write: > But for the latter something just a little more than minimal hacks > must be implemented. But dynamic cpu enable/disable is definitely > worth it. Perhaps I didn't make myself clear: hotplugging does not neccessarily mean physically removing or adding the CPU. And as to whether they offer full support, or stub support, architectures can decide that for themselves, as they need. It's not my call. I don't know how much of a win it is to disable HT on cpus, but I can tell you that adding & subtracting CPUs is a fairly heavy-weight operation in this design (I don't think we really want to lock around every cpu iteration). Rusty. -- Anyone who quotes me in their sig is an idiot. -- Rusty Russell. - 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/