On Mon, 2010-01-18 at 18:29 +0100, Frederic Weisbecker wrote: > On Mon, Jan 18, 2010 at 06:13:26PM +0100, Peter Zijlstra wrote: > > On Mon, 2010-01-18 at 17:51 +0100, Frederic Weisbecker wrote: > > > > > Right hw_perf_enable/disable have no action on breakpoint events. > > > These were somehow considered as software events until now. > > > > > > That raises the question: why perf_disable() only takes care > > > of hardware events? Very few software events can trigger > > > between perf_disable() and perf_enable() sections though. > > > > > > May be I should handle breakpoints there. > > > > OK, so maybe I'm not understanding the breakpoint stuff correctly, why > > is it modeled as a software pmu? It has resource constraints like a > > hardware pmu. > > > It doesn't use the software pmu, it uses its own. But what kind > of properties can it share with other hardware events? > > It has constraints that only need to be checked when we register > the event. It has also constraint on enable time but nothing > tricky that requires an overwritten group scheduling.
the only group scheduling bit is hw_perf_group_sched_in(), and I guess you can get away without hw_perf_disable() because it doesn't generate nmis, although I'd have to audit the code to verify a properly placed breakpoint won't trip things up, since the core code basically assumes counters won't trigger within perf_disable/enable sections. ------------------------------------------------------------------------------ Throughout its 18-year history, RSA Conference consistently attracts the world's best and brightest in the field, creating opportunities for Conference attendees to learn about information security's most important issues through interactions with peers, luminaries and emerging and established companies. http://p.sf.net/sfu/rsaconf-dev2dev _______________________________________________ perfmon2-devel mailing list perfmon2-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/perfmon2-devel
