Prev: "m68k: Cleanup linker scripts using new linker script macros." and old binutils (was: Re: [PATCH] m68k: Atari EtherNAT - Nicolas Pitre has a new email address)
Next: Something has been broken in the network stack this week
From: Paul Mackerras on 10 Jan 2010 17:10
Frederic,

Nice to see someone working on the event scheduling in perf.

But I don't think this patch makes sense:

> Group of flexible events are round-robined in each tick so that
> each group has its chance to be scheduled. But the fairness
> per group granularity doesn't propagate inside the groups
> themselves.
>
> If only the first events of each groups have a chance to make
> their way, the remaining ones will never be scheduled.
>
> Hence this patch propagates the round-robin to the events
> inside the groups.

The semantic of a group is that either all of the events in the group
are scheduled in, or none of them are. So it doesn't make sense to
talk about fairness within a group, and I don't see any point to
rotating the elements of the sibling_list. Or have I misunderstood
what you're aiming at?

Paul.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: Paul Mackerras on 10 Jan 2010 19:40
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.

Paul.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
 | 
Pages: 1
Prev: "m68k: Cleanup linker scripts using new linker script macros." and old binutils (was: Re: [PATCH] m68k: Atari EtherNAT - Nicolas Pitre has a new email address)
Next: Something has been broken in the network stack this week