linux-kernel - Re: [REGRESSION] x86, perf: counter freezing breaks rr

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: <20181120201144.GD13936@tassilo.jf.intel.com>
Date:   Tue, 20 Nov 2018 12:11:44 -0800
From:   Andi Kleen <ak@...ux.intel.com>
To:     Kyle Huey <me@...ehuey.com>
Cc:     Kan Liang <kan.liang@...ux.intel.com>,
        "Peter Zijlstra (Intel)" <peterz@...radead.org>,
        Ingo Molnar <mingo@...nel.org>,
        Robert O'Callahan <robert@...llahan.org>,
        Alexander Shishkin <alexander.shishkin@...ux.intel.com>,
        Arnaldo Carvalho de Melo <acme@...hat.com>,
        Jiri Olsa <jolsa@...hat.com>,
        Linus Torvalds <torvalds@...ux-foundation.org>,
        Stephane Eranian <eranian@...gle.com>,
        Thomas Gleixner <tglx@...utronix.de>,
        Vince Weaver <vincent.weaver@...ne.edu>, acme@...nel.org,
        open list <linux-kernel@...r.kernel.org>
Subject: Re: [REGRESSION] x86, perf: counter freezing breaks rr

> > > Given that we're already at rc3, and that this renders rr unusable,
> > > we'd ask that counter freezing be disabled for the 4.20 release.
> >
> > The boot option should be good enough for the release?
> 
> I'm not entirely sure what you mean here. We want you to flip the
> default boot option so this feature is off for this release. i.e. rr
> should work by default on 4.20 and people should have to opt into the
> inaccurate behavior if they want faster PMI servicing.

I don't think it's inaccurate, it's just different 
than what you are used to.

For profiling including the kernel it's actually far more accurate
because the count is stopped much earlier near the sampling
point. Otherwise there is a considerable over count into
the PMI handler.

In your case you limit the count to ring 3 so it's always cut off
at the transition point into the kernel, while with freezing
it's at the overflow point.

-Andi