Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1757602AbZKRXTH (ORCPT ); Wed, 18 Nov 2009 18:19:07 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1755547AbZKRXTG (ORCPT ); Wed, 18 Nov 2009 18:19:06 -0500 Received: from terminus.zytor.com ([198.137.202.10]:45786 "EHLO terminus.zytor.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753904AbZKRXTE (ORCPT ); Wed, 18 Nov 2009 18:19:04 -0500 Message-ID: <4B0480C4.6080003@zytor.com> Date: Wed, 18 Nov 2009 15:18:28 -0800 From: "H. Peter Anvin" User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.4pre) Gecko/20091014 Fedora/3.0-2.8.b4.fc11 Thunderbird/3.0b4 MIME-Version: 1.0 To: Roland McGrath CC: Jason Baron , linux-kernel@vger.kernel.org, mingo@elte.hu, mathieu.desnoyers@polymtl.ca, tglx@linutronix.de, rostedt@goodmis.org, andi@firstfloor.org, rth@redhat.com, mhiramat@redhat.com Subject: Re: [RFC PATCH 0/6] jump label v3 References: <4B047A81.3060104@zytor.com> <20091118230758.0C49A9D5@magilla.sf.frob.com> In-Reply-To: <20091118230758.0C49A9D5@magilla.sf.frob.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1294 Lines: 26 On 11/18/2009 03:07 PM, Roland McGrath wrote: >> 67 66 8D 74 00 (lea si,[si+0]) should work as a 32-bit atomic NOP. It's >> not necessarily the fastest, though (I have no data on that.) >> Similarly, 66 66 66 66 90 should also work. > > We should get all the knowledge like that stored in places like the > Kconfig.cpu comments near X86_P6_NOP and/or asm/nops.h macros and comments. > > Let's have an ASM_ATOMIC_NOP5 macro in asm/nops.h? I've lost track of the > variants, and I'll leave that to you all who are close to the chip people. > > I can't tell if it's the case that there will be kernel configurations > where there is one known-safe choice but a different choice that's optimal > if CPU model checks pass. If so, we could compile in the safe choice and > then mass-change to the optimal choice at boot time. (i.e. like the > alternatives support, but we don't really need to use that too since we > already have another dedicated table of all the PC addresses to touch.) Yes, I believe we do something like that already. -hpa -- 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/