Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752194Ab2FETyX (ORCPT ); Tue, 5 Jun 2012 15:54:23 -0400 Received: from mga09.intel.com ([134.134.136.24]:47710 "EHLO mga09.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750879Ab2FETyV convert rfc822-to-8bit (ORCPT ); Tue, 5 Jun 2012 15:54:21 -0400 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="4.67,351,1309762800"; d="scan'208";a="153314822" From: "Luck, Tony" To: Peter Zijlstra CC: "Yu, Fenghua" , Rusty Russell , Thomas Gleixner , Ingo Molnar , H Peter Anvin , "Siddha, Suresh B" , "Mallick, Asit K" , Arjan Dan De Ven , linux-kernel , x86 , linux-pm , "Srivatsa S. Bhat" Subject: RE: [PATCH 0/6] x86/cpu hotplug: Wake up offline CPU via mwait or nmi Thread-Topic: [PATCH 0/6] x86/cpu hotplug: Wake up offline CPU via mwait or nmi Thread-Index: AQHNQoAPFj9sktPv9UGlpY91mwdZJJbrDNOAgAAGFYCAAEURgIAAdQ+AgACMaICAAAIPgIAAApCAgAAAWQD//6AhUIAAffCA//+mwpA= Date: Tue, 5 Jun 2012 19:54:19 +0000 Message-ID: <3908561D78D1C84285E8C5FCA982C28F19301A16@ORSMSX104.amr.corp.intel.com> References: <1338833876-29721-1-git-send-email-fenghua.yu@intel.com> <1338842001.28282.135.camel@twins> <87zk8iioam.fsf@rustcorp.com.au> <1338881971.28282.150.camel@twins> <3E5A0FA7E9CA944F9D5414FEC6C7122007727023@ORSMSX105.amr.corp.intel.com> <1338912565.2749.9.camel@twins> <3E5A0FA7E9CA944F9D5414FEC6C7122007728081@ORSMSX105.amr.corp.intel.com> <1338913190.2749.10.camel@twins> <3908561D78D1C84285E8C5FCA982C28F19300965@ORSMSX104.amr.corp.intel.com> <1338919647.2749.30.camel@twins> In-Reply-To: <1338919647.2749.30.camel@twins> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.22.254.139] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 8BIT MIME-Version: 1.0 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1036 Lines: 22 > But given that you care about how fast a cpu can come up again, this > seems to be exactly what you want. You want to adapt to load fast, so > why bother going through userspace and wrecking bits in between? There are multiple needs here - that appear to have some significant overlap (re-routing interrupts, stopping scheduling). My need is for RAS reasons to take a cpu offline - and since it is broken, I'm not going to bring it back again (at least not anytime soon - perhaps a service engineer will drive by in a few hours, pull out the broken cpu, put in a new one, and then bring that online ... but saving a few milli-seconds in this use case it pointless). Other people want to do this for power saving. They probably do care how fast the processor can be brought back. -Tony -- 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/