linux-kernel - Re: [PATCH] perf, x86: catch spurious interrupts after disabling counters

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: <20100916145132.GB5352@nowhere>
Date:	Thu, 16 Sep 2010 16:51:36 +0200
From:	Frederic Weisbecker <fweisbec@...il.com>
To:	Robert Richter <robert.richter@....com>
Cc:	Stephane Eranian <eranian@...gle.com>,
	Cyrill Gorcunov <gorcunov@...il.com>,
	Ingo Molnar <mingo@...e.hu>,
	Peter Zijlstra <peterz@...radead.org>,
	Don Zickus <dzickus@...hat.com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"ying.huang@...el.com" <ying.huang@...el.com>,
	"ming.m.lin@...el.com" <ming.m.lin@...el.com>,
	"yinghai@...nel.org" <yinghai@...nel.org>,
	"andi@...stfloor.org" <andi@...stfloor.org>
Subject: Re: [PATCH] perf, x86: catch spurious interrupts after disabling
	counters

On Thu, Sep 16, 2010 at 12:27:12AM +0200, Robert Richter wrote:
> > On Wed, Sep 15, 2010 at 10:21:10PM +0200, Stephane Eranian wrote:
> > > When you do perf record foo, it's equivalent to
> > > perf record -e cycles:uk -F 1000 foo
> 
> Yes, thanks.
> 
> I am asking because I have observed up to 4 back-to-back nmis from the
> same counter when enabling an event. The period is not yet adjusted.
> We should avoid those short sampling periods in the beginning and
> better start with too long periods. Didn't look at the implementation
> so far. I know this is not easy to handle because this very much
> depends on the event we measure.
> 
> Maybe we start the counter with a delay and then calculate period =
> duration - delay, later decreasing the delay until the frequency is
> adjusted but keeping the total sampling rate more or less constant.


Yep, IIRC, the first arming is set with a 1 sample period. So that a first
calculation can be made on top of the first triggering event time to get
a better sample period. That avoids the need to start with frequency
nature assumptions for each event.

I doubt that can be worked around easily.

--
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/