On Thu, 2010-01-07 at 10:54 +0100, Stephane Eranian wrote: > > Ok, so I made some progress yesterday on all of this. > > The key elements are: > - pmu->enable() is always called from generic with PMU disabled > - pmu->disable() is called with PMU possibly enabled > - hw_perf_group_sched_in() is always called with PMU disabled > > I got the n_added logic working now on X86. > > I noticed the difference in pmu->enabled() between Power and X86. > On PPC, you disable the whole PMU. On X86, that's not the case. > > Now, I do the scheduling in hw_perf_enable(). Just like on PPC, I also > move events around if their register assignment has changed. It is not > quite working yet. I must have something wrong with the read and rewrite > code. > > I will experiment with pmu->enable(). Given the key elements above, I think > Paul is right, all scheduling can be deferred until hw_perf_enable(). > > But there is a catch. I noticed that hw_perf_enable() is void. In > other words, it > means that if scheduling fails, you won't notice. This is not a problem on PPC > but will be on AMD64. That's because the scheduling depends on what goes on > on the other cores on the socket. In other words, things can change between > pmu->enable()/hw_perf_group_sched_in() and hw_perf_enable(). Unless we lock > something down in between.
You have to lock stuff, you can't fail hw_perf_enable() because at that point we've lost all track of what failed. ------------------------------------------------------------------------------ This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev _______________________________________________ perfmon2-devel mailing list perfmon2-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/perfmon2-devel
