Re: What is the right practice to get new code upstream( was Fwd: [patch] a simple hardware detector for latency as well as throughput ver. 0.1.0)

[Peter Zijlstra <a.p.zijlstra@chello.nl>]

On Thu, 2012-06-21 at 15:29 +0200, Robert Richter wrote:
> On 14.06.12 12:04:56, Peter Zijlstra wrote:
>  For AMD there's only event 02Bh, which is SMIs Received. I'm not sure it
> > has anything like the FREEZE or if the event is modifyable to count the
> > cycles in SMI.
> 
> Peter, which use cases do you have in mind. Is it to root cause
> latencies? Or just to see what happens on the system, you long it
> spends in smi mode? On current systems counting smi cycles seems not
> to be possible.

Yeah exactly. So we can whack vendors over the head with hard evidence
their BIOS is utter shite.

So what we do now is disable interrupts, run a tight TSC read loop and
report fail when you see a big delta.

Now some 'creative' BIOS people thought it would be a good idea to
save/restore TSC over the SMI, this avoids detection. It also completely
wrecks TSC sync across cores.

But the SMI stuff is a real problem for -rt, this feature^Wfailure-add
is a real problem, we've seen SMIs that go well above a ms in duration,
which of course completely wreck the system.

IIRC the worst tglx ever encountered was 0.5s or so.

So ideally the PMU would have 2 events, one counting SMIs one counting
cycles in SMM. Both should ignore any and all FREEZE_IN_SMM bits if such
a thing exists. The hardware should also hard fail if such a counter is
fiddled with from SMM context.

This would give us the capability to log exactly when and for how long
the system is taken from us and makes it impossible to 'fix' from SMM.