Messages in this thread | | | Date | Mon, 11 Jan 2010 02:56:35 +0100 | From | Frederic Weisbecker <> | Subject | Re: [PATCH 6/6] perf: Increase round-robin fairness of flexible events |
| |
On Mon, Jan 11, 2010 at 11:39:05AM +1100, Paul Mackerras wrote: > On Mon, Jan 11, 2010 at 12:57:59AM +0100, Frederic Weisbecker wrote: > > > I think the constraint of "either every or none get > > scheduled in a group" makes a lot of sense for pinned > > groups. > > > > But I don't see the point in applying this > > rule inside flexible groups because the nature > > of flexible events implies these have been created to > > fight against a limited resource. So if this fight > > is done only between groups, this is like raising > > a voluntary starvation. > > > > Or..or..May be I just realize too late that the semantic > > of a group implies that all events inside must be always > > counted simultaneously? In which case I agree with you, > > this patch makes no sense and must be dropped. > > The original idea of the groups was for situations where you want to > take the difference or ratio of two counts. For example, if you want > to measure cache hits but the hardware can only count cache accesses > and cache misses. In that situation you want to compute accesses > minus misses, but if the counters for accesses and for misses are > independently scheduled, statistical fluctuations can mean there is a > lot of noise in the result, and it might even be negative. Putting > the two counters into one group means that you can meaningfully > compute the difference or ratio since the two counter values relate to > the same set of instructions (even if that isn't the whole execution > of the program). > > The default situation is that each event is in its own group, so the > starvation you talk about won't arise. If the user has gone to the > trouble of putting two events into one group, then they are saying > that they need the events to be scheduled on and off together, and if > that leads to starvation, that's unfortunate but we can't do any > better within the limitations of the hardware.
Agreed. This patch came from my misunderstanding of the purpose of groups.
| |