Re: [PATCH] perf_events: fix validate_event bug

[stephane eranian <eranian@googlemail.com>]

On Tue, Nov 24, 2009 at 11:00 PM, Paul Mackerras <paulus@samba.org> wrote:
> stephane eranian writes:
>
>> That means we can drop is_software_event() in this code and instead
>> define locally
>> in x86 a is_hw_pmu_event() function as event->pmu == &pmu.
>
> I'd have to see the patch, but that doesn't feel entirely right,
> because there is a unique characteristic of software events, compared
> to hardware or breakpoint events: they are never capacity
> constrained.  In the past, only hardware events were capacity
> constrained, which meant that all the decisions about whether a group
> could go on could be done in the hardware PMU backend.  Now we have
> two sources of capacity constraints, so it may be that a group can't
> go on even if the hardware PMU has capacity.  That's going to be
> somewhat interesting to get completely right, I think.
>
I was talking of is_software_event() in the context of the hardware PMU
code. The reason you were using this function is simply to skip
SW events because, as you said, they are never constrained
and also because they are not related to HW PMU.

You are right about HW breakpoints, because now you have a new source of
constraints. Only the breakpoint code knows about those constraints.

It seems to me you have two ways of solving this:
  1- push the algorithm to assign events to counters up in the generic code
  2- have the generic code invoke all possible constraint sources on each group

I have already said that I would not recommend initially going with 1- because
constraints are very diverse in their nature. It is not as simple as 1 event = 1
bitmask of valid counters. Things can be more dynamic than that, e.g., on AMD64,
whereby for certain events the bitmask depends on what is going on in the other
cores on the socket. There are also similar constraints on advanced
Intel features.
So unlike what I heard early on, constraints are not going away,
instead they are
changing in nature and to something much more complex to deal with.

I believe that until all PMU event assignment logic is implemented in the PMU
specific code, it would be very presumptuous to try and design that
generic algorithm.
So I would go with 2, at least initially.