[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <alpine.LFD.2.01.0906151135500.6276@localhost.localdomain>
Date: Mon, 15 Jun 2009 11:51:19 -0700 (PDT)
From: Linus Torvalds <torvalds@...ux-foundation.org>
To: Ingo Molnar <mingo@...e.hu>
cc: Mathieu Desnoyers <mathieu.desnoyers@...ymtl.ca>, mingo@...hat.com,
hpa@...or.com, paulus@...ba.org, acme@...hat.com,
linux-kernel@...r.kernel.org, a.p.zijlstra@...llo.nl,
penberg@...helsinki.fi, vegard.nossum@...il.com, efault@....de,
jeremy@...p.org, npiggin@...e.de, tglx@...utronix.de,
linux-tip-commits@...r.kernel.org
Subject: Re: [tip:perfcounters/core] perf_counter: x86: Fix call-chain support
to use NMI-safe methods
On Mon, 15 Jun 2009, Ingo Molnar wrote:
>
> [ If on the other hand it's a speedup of a few cycles then we have
> the problem of me suddenly liking this patch a whole lot more ;-) ]
I missed the patch.
It's quite possible that replacing "iret" with a regular "ret" (for the
kernel->kernel transition) is a real speedup. That said, there's a few
things to think about:
- CPU return stack caches/predictors. I suspect that "iret" and
exceptions don't generally touch them (but who knows - maybe they do),
while a regular "ret" definitely does. I dunno about "retf".
This can cause very subtle performance slowdowns, where the slowdown
happens somewhere else. And it could be _very_ uarch-dependent (ie only
happen on some architectures, while having no performance downside on
others)
- kernel->kernel exceptions _should_ be rare, with the exception of
actual real external interrupts. So the path to optimize should always
be the user-space exception path. That one will need 'iret', but I'd
also not want to see more testing in that hot-path. I suspect we
already always test for user-mode anyway (due to signal handling etc
work), but if it adds new tests to that path, any kernel->kernel
speedup is likely totally pointless.
That said, it would be nice to avoid 'iret' if only because of its subtle
interactions with the while NMI flag.
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