> 6/ Group scheduling > > Looking at the existing code, it seems to me there is a risk of > starvation for groups, i.e., groups never scheduled on the PMU. > > My understanding of the scheduling algorithm is: > > - first try to �schedule pinned groups. If a pinned group > fails, put it in error mode. read() will fail until the > group gets another chance at being scheduled. > > - then try to schedule the remaining groups. If a group fails > just skip it. > > If the group list does not change, then certain groups may always > fail. However, the ordering of the list changes because at every > tick, it is rotated. The head becomes the tail. Therefore, each > group eventually gets the first position and therefore gets the > full PMU to assign its events. > > This works as long as there is a guarantee the list will ALWAYS > rotate. If a thread does not run long enough for a tick, it may > never rotate.
You need to ensure the task never runs during the tick, this is a statistical propery that is bound to untrue for any 'normal' application. This is similar to the old cputime hiding tricks. We don't think this will be a problem, you really need to actively avoid the tick to aggregate a significantly lower tick rate. In any case this can also be excluded via a natural extension mentioned above: scheduling based not on the scheduler tick but based on one of the counters. ------------------------------------------------------------------------------ Are you an open source citizen? Join us for the Open Source Bridge conference! Portland, OR, June 17-19. Two days of sessions, one day of unconference: $250. Need another reason to go? 24-hour hacker lounge. Register today! http://ad.doubleclick.net/clk;215844324;13503038;v?http://opensourcebridge.org _______________________________________________ perfmon2-devel mailing list perfmon2-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/perfmon2-devel
