[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <alpine.LFD.1.10.0804250908570.2779@woody.linux-foundation.org>
Date: Fri, 25 Apr 2008 09:11:59 -0700 (PDT)
From: Linus Torvalds <torvalds@...ux-foundation.org>
To: Ingo Molnar <mingo@...e.hu>
cc: Jiri Slaby <jirislaby@...il.com>,
David Miller <davem@...emloft.net>, zdenek.kabelac@...il.com,
rjw@...k.pl, paulmck@...ux.vnet.ibm.com, akpm@...ux-foundation.org,
linux-ext4@...r.kernel.org, herbert@...dor.apana.org.au,
penberg@...helsinki.fi, clameter@....com,
linux-kernel@...r.kernel.org,
Mathieu Desnoyers <mathieu.desnoyers@...ymtl.ca>,
Andi Kleen <andi@...stfloor.org>, pageexec@...email.hu,
"H. Peter Anvin" <hpa@...or.com>,
Jeremy Fitzhardinge <jeremy@...p.org>
Subject: Re: [PATCH 1/1] x86: fix text_poke
On Fri, 25 Apr 2008, Ingo Molnar wrote:
>
> text_poke() itself only applies/unapplies the LOCK prefix - a single
> byte. We shouldnt be doing that at all: the cost of LOCK is
> insignificant (a few cycles) and most systems are SMP anyway.
No, the cost of LOCK is quite high on a lot of systems.
On P4's in particular, since LOCK is serializing, it's about 140 cycles or
so (and breaks all speculation). So we definitely want to remove it for
any generic kernels.
(lock is fairly cheap on AMD K8's, and reportedly on Intel's upcoming
Nehalem too, but on Core 2 it's about 35 cycles - quite noticeable,
although not nearly the disaster that netburst is)
Oh, and text_poke() is also used for inserting the debug instruction for
kprobes (and restoring the original byte), but yes, that is always just a
single byte too.
Linus
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists