Re: [tip:perfcounters/core] perf_counter: x86: Fix call-chain support to use NMI-safe methods

Mathieu Desnoyers
2009-06-15T19:22:13Z

* Linus Torvalds (torvalds@linux-foundation.org) wrote:
>
>
> 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".
>

Also, I don't think popf acts as a serializing instruction. (reading the
Intel Architecture Software Developer's Manual, vol 3 System programming
section 7.4 Serializing Instructions). And ret clearly doesn't.
Therefore I'd be worried of iret serialization assumptions which could
be done within the kernel code. Maybe it would be safer to add a cpuid
or mfence instruction in there to ensure correct core serialization.

This would turn the hand-made iret into a :

popf
mfence
ret

Or something like that.

Mathieu

> 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

--
Mathieu Desnoyers
OpenPGP key fingerprint: 8CD5 52C3 8E3C 4140 715F BA06 3F25 A8FE 3BAE 9A68