On Wed, Aug 28, 2019 at 08:11:51PM -0700, Andi Kleen wrote: > On Wed, Aug 28, 2019 at 06:28:57PM +0200, Peter Zijlstra wrote: > > On Wed, Aug 28, 2019 at 09:17:54AM -0700, Andi Kleen wrote: > > > > This really doesn't make sense to me; if you set FIXED_CTR3 := 0, you'll > > > > never trigger the overflow there; this then seems to suggest the actual > > > > > > The 48bit counter might overflow in a few hours. > > > > Sure; the point is? Kan said it should not be too big; a full 48bit wrap > > around must be too big or nothing is. > > We expect users to avoid making it too big, but we cannot rule it out. > > Actually for the common perf stat for a long time case you can make it fairly > big because the percentages still work out over the complete run time. > > The problem with letting it accumulate too much is mainly if you > want to use a continuously running metrics counter to time smaller > regions by taking deltas, for example using RDPMC. > > In this case the small regions would be too inaccurate after some time. > > But to make the first case work absolutely need to handle the overflow > case. Otherwise the metrics would just randomly stop at some > point.
But then you need -max_period, not 0. By using half the period, there is no ambiguity on overflow.
