Messages in this thread | | | Date | Mon, 22 Jun 2009 13:53:10 +0200 | From | Ingo Molnar <> | Subject | Re: I.6 - Group scheduling |
| |
> 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. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |