linux-kernel - Re: [PATCH 1/4] x86, perf: Use a new PMU ack sequence on Skylake

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20151016133514.GB15102@tassilo.jf.intel.com>
Date:	Fri, 16 Oct 2015 06:35:14 -0700
From:	Andi Kleen <ak@...ux.intel.com>
To:	Peter Zijlstra <peterz@...radead.org>
Cc:	Andi Kleen <andi@...stfloor.org>, linux-kernel@...r.kernel.org,
	Ingo Molnar <mingo@...nel.org>,
	Thomas Gleixner <tglx@...utronix.de>
Subject: Re: [PATCH 1/4] x86, perf: Use a new PMU ack sequence on Skylake

> What would happen with a 'stuck' event in the new scheme?

The usual reason events are stuck is that perf programs a too low period
in frequency mode after fork.

We have two safety mechanisms:

- The perf overflow code checks against the max number of
overflows per second, and forces a lower period if needed.
- The NMI duration limiter checks the total length of NMI

With the low period problem it will bump into the first limit.
The second limit also makes sure not too much CPU time is lost.

It wouldn't handle a case where the interrupt handler gets 
re-issued without overflowing, but I don't think that can
really happen (except for the check point case, which is
also covered)

> > In principle the sequence should work on other CPUs too, but
> > since I only tested on Skylake it is only enabled there.
> 
> I would very much like a reduction of the ack states. You introduced the
> late thing, which should also work for everyone, and now you introduce
> yet another variant.

Ingo suggested to do it this way. Originally I thought it wasn't needed,
but I think now that late-ack made some of the races that eventually
caused Skylake LBR to fall over worse. So in hindsight it was a good idea
to not use it everywhere. 

> I would very much prefer a single ack scheme if at all possible.

Could enable it everywhere, but then users would need to test it
on most types of CPUs, as I can't.

-Andi

-- 
ak@...ux.intel.com -- Speaking for myself only
--
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/