From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1758183AbYHOWvJ (ORCPT ); Fri, 15 Aug 2008 18:51:09 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1752222AbYHOWu4 (ORCPT ); Fri, 15 Aug 2008 18:50:56 -0400 Received: from gw.goop.org ([64.81.55.164]:42528 "EHLO mail.goop.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752121AbYHOWuz (ORCPT ); Fri, 15 Aug 2008 18:50:55 -0400 Message-ID: <48A6082E.70405@goop.org> Date: Fri, 15 Aug 2008 15:50:22 -0700 From: Jeremy Fitzhardinge User-Agent: Thunderbird 2.0.0.16 (X11/20080723) MIME-Version: 1.0 To: Linus Torvalds CC: "H. Peter Anvin" , Ingo Molnar , Steven Rostedt , LKML , Thomas Gleixner , Peter Zijlstra , Andrew Morton , David Miller , Mathieu Desnoyers , Roland McGrath , Ulrich Drepper , Rusty Russell , Gregory Haskins , Arnaldo Carvalho de Melo , "Luis Claudio R. Goncalves" , Clark Williams , srostedt@redhat.com Subject: Re: [PATCH] ftrace: use only 5 byte nops for x86 References: <48A4C491.4050301@goop.org> <20080815092231.GB22209@elte.hu> <48A6037B.6030202@zytor.com> In-Reply-To: X-Enigmail-Version: 0.95.7 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 Linus Torvalds wrote: > I also suspect that we'd really be much better off just fixing the generic > NOP tables for the 5-byte nop. As far as I could tell, from all the > numbers that have been posted, absolutely _none_ show that there is any > point at all to the 2-instruction 3/2-byte sequence. > > So instead of having a magic special ftrace-only thing, why not just do it > right, and fix the generic 5-byte nop sequence? > Well, there's two distinct issues here. There's the need for a single-instruction 5 byte nop, and the need for efficient nops. It so happens in this case that they're the same thing. But in general, the generic nop interface is intended to return the most efficient nop, not an atomic nop (or with any other properties). To handle it generically, we'd either need to redefine the meaning of the existing nop-padding interface, or add an "atomic nop" interface. J