[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <alpine.LFD.1.10.0804250915340.2779@woody.linux-foundation.org>
Date: Fri, 25 Apr 2008 09:24:11 -0700 (PDT)
From: Linus Torvalds <torvalds@...ux-foundation.org>
To: Andi Kleen <andi@...stfloor.org>
cc: Ingo Molnar <mingo@...e.hu>, 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>,
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, Andi Kleen wrote:
>
> Not sure how the fixmap is better. It's pretty much equivalent, isn't it?
> Perhaps a little cheaper, but the code shouldn't be performance critical.
I have no really strong opinions. However, we do have a *lot* of lock
prefixes in the kernel, and fixmaps are a lot cheaper than vmap(). It may
not be performance-critical, but for me the "locks" section for the kernel
is 0x8060 bytes long, which would seem to say that this is called four
thousand times for each suspend and resume.
With each invocation being thousands of instructions and a cross-CPU IPI
for the tlb flush, that kind of stuff adds up. We're likely talking real
fractions of a second, rather than milliseconds.
But no, I didn't time it or really think very deeply about it.
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