Messages in this thread | | | Date | Wed, 17 Dec 2008 08:45:01 +0100 | From | "stephane eranian" <> | Subject | Re: [patch] Performance Counters for Linux, v3 |
| |
On Mon, Dec 15, 2008 at 11:32 PM, Chris Friesen <cfriesen@nortel.com> wrote: > stephane eranian wrote: >> >> On Fri, Dec 12, 2008 at 8:45 PM, Chris Friesen <cfriesen@nortel.com> >> wrote: >> >>> stephane eranian wrote: >>> >>> >>>> What happens in the following test case: >>>> >>>> - 2-way system (cpu0, cpu1) >>>> >>>> - on cpu0, two processes P1, P2, each self-monitoring and counting >>>> event >>>> E1. >>>> Event E1 can only be measured on counter C1. >>>> >>>> - on cpu1, there is a cpu-wide session, monitoring event E1, thus using >>>> C1 >>>> >>>> - the scheduler decides to migrate P1 onto CPU1. You now have a >>>> conflict on C1. >>>> >>>> How is this managed? >>> >>> Prevent the load balancer from moving P1 onto cpu1? >>> >> >> You don't want to do that. >> >> There was a reason why the scheduler decided to move the task. >> Now, because of monitoring you would change the behavior of the task >> and scheduler. >> Monitoring should be unintrusive. You want the task/scheduler to >> behave as if no monitoring >> was present otherwise what is it you are actually measuring? > > In a scenario where the system physically cannot gather the desired data > without influencing the behaviour of the program, I see two options: > > 1) limit the behaviour of the system to ensure that we can gather the > performance monitoring data as specified > > 2) limit the performance monitoring to minimize any influence on the > program, and report the fact that performance monitoring was limited. > > You've indicated that you don't want option 1, so I assume that you prefer > option 2. In the above scenario, how would _you_ handle it? > That's right, you have to fail monitoring.
In this particular example, it is okay for per-thread sessions to each use C1. Any cpu-wide session trying to access C1 should fail. Vice versa if a cpu-wide session is using C1, then no per-thread session can be accessing it.
Things can get even more complicated than that even for per-thread sessions. Some PMU registers may be shared per core, e.g, Nehalem or Pentium 4. Thus if HT is enabled, you also have to fail per-thread sessions, as only one can grab the resource globally.
| |