perf test pmu-events question

perf test pmu-events question

[John Garry]

Hi Ian,

I was doing some re-write for pmu sys events metric support and I want 
to add more testcases - we don't really have any.

So I noticed that tests/pmu-events.c::test__parsing() can pick up on an 
invalid metric for the test CPU, like M3 as it references itself. 
However we can't detect whether event aliases referenced in the metric 
exist for the CPU. Is it worth testing for this? Would it be sane to 
scan the associated CPU event tables to see if we can find the event 
there? Or do we already have some per-non-test-CPU metric validator 
already in the testcases (I could not see it)?

Thanks,
John

Re: perf test pmu-events question

[Ian Rogers]

On Fri, Jun 23, 2023 at 8:20 AM John Garry <john.g.garry@oracle.com> wrote:
>
> Hi Ian,
>
> I was doing some re-write for pmu sys events metric support and I want
> to add more testcases - we don't really have any.
>
> So I noticed that tests/pmu-events.c::test__parsing() can pick up on an
> invalid metric for the test CPU, like M3 as it references itself.
> However we can't detect whether event aliases referenced in the metric
> exist for the CPU. Is it worth testing for this? Would it be sane to
> scan the associated CPU event tables to see if we can find the event
> there? Or do we already have some per-non-test-CPU metric validator
> already in the testcases (I could not see it)?


Hi John,

we always need more tests :-) For Intel there has historically been a
problem that the names in metrics and the event data will get out of
alignment. There is a best effort test during the metric generation
that this doesn't happen any more here:
https://github.com/intel/perfmon/blob/main/scripts/create_perf_json.py#L1171-L1188
But still things get messed up, such as PMU names being mismatched -
when this happens the JSON events just don't appear at runtime. We
could try to replicate the event matching logic at creation time in
jevents.py and that should do what you mention and be
multi-architecture. The metric test tests every metric produces an
output, and this fails when event parsing fails, so this has
traditionally been the way to find bad metrics. We do have build time
tests like:
https://git.kernel.org/pub/scm/linux/kernel/git/perf/perf-tools-next.git/tree/tools/perf/pmu-events/Build?h=perf-tools-next#n30

Intel don't have JSON encodings for the TSX events and so they use
sysfs events and this is what motivated the has_event test:
https://lore.kernel.org/linux-perf-users/20230623151016.4193660-1-irogers@google.com/

Some other thoughts in this area:
1) I'd like to get sysfs snapshots so that we can get things like
parse-events coverage of heterogeneous PMUs without needing such a
system.
2) The largest part of the perf binary is the json data. I'd like to
convert the json data to a sysfs style, then compress it in a way
where we benefit from duplication between files (zip can't do this,
but tgz or 7zip can). libarchive can load these formats from memory.
The current json data on x86 converts to about 7MB of read-only data,
but the same json files compress down to about 1.5MB. The perf binary
is about 3MB of code, so doing the compression should hopefully make
the file size about half what it currently is and do something to stem
the problem of the binary slowly growing over time with new
architecture releases.
3) I'm hoping we can do something like a unionfs with the in memory
sysfs, on disk sysfs tar balls and the like, and the machine's actual
sysfs so that we can just have one consistent view in the tool.
4) I want to make PMUs lazier so that we don't need to eagerly load
all the events. The cycles event doesn't need json or sysfs data, but
it is all still loaded due to wanting the PMU. This faults in a lot of
JSON data on x86 that is then never used.

Thanks,
Ian

> Thanks,
> John
>
>

Re: perf test pmu-events question

[John Garry]

On 23/06/2023 16:48, Ian Rogers wrote:
> On Fri, Jun 23, 2023 at 8:20 AM John Garry <john.g.garry@oracle.com> wrote:
>>
>> Hi Ian,
>>
>> I was doing some re-write for pmu sys events metric support and I want
>> to add more testcases - we don't really have any.
>>
>> So I noticed that tests/pmu-events.c::test__parsing() can pick up on an
>> invalid metric for the test CPU, like M3 as it references itself.
>> However we can't detect whether event aliases referenced in the metric
>> exist for the CPU. Is it worth testing for this? Would it be sane to
>> scan the associated CPU event tables to see if we can find the event
>> there? Or do we already have some per-non-test-CPU metric validator
>> already in the testcases (I could not see it)?
> 

Hi Ian,

Thanks for getting back to me.

> 
> Hi John,
> 
> we always need more tests :-)

Sure

> For Intel there has historically been a
> problem that the names in metrics and the event data will get out of
> alignment. There is a best effort test during the metric generation
> that this doesn't happen any more here:
> https://urldefense.com/v3/__https://github.com/intel/perfmon/blob/main/scripts/create_perf_json.py*L1171-L1188__;Iw!!ACWV5N9M2RV99hQ!OKyD56aIReczgaPkGD3MZ0yZ-WFe7qXps1aFyF6pibEN8nk0r4N5Y87MgV0twed_V8E8l7kjJd88_AjTGW8$

Does that validate alias event support for the CPU? It seems that the 
specific lines mentioned are just checking for keywords.

> But still things get messed up, such as PMU names being mismatched -
> when this happens the JSON events just don't appear at runtime. We
> could try to replicate the event matching logic at creation time in
> jevents.py and that should do what you mention and be
> multi-architecture.

OK, that could work. It is limited to testing just aliases, which I 
suppose has some value.

However I am not sure how well this would suit testing sys event metric 
support, where I want to ensure that a specific event alias is chosen 
for a metric in the same pmu_sys_events struct.

> The metric test tests every metric produces an
> output, and this fails when event parsing fails, so this has
> traditionally been the way to find bad metrics. 
>We do have build time
> tests like:
> https://urldefense.com/v3/__https://git.kernel.org/pub/scm/linux/kernel/git/perf/perf-tools-next.git/tree/tools/perf/pmu-events/Build?h=perf-tools-next*n30__;Iw!!ACWV5N9M2RV99hQ!OKyD56aIReczgaPkGD3MZ0yZ-WFe7qXps1aFyF6pibEN8nk0r4N5Y87MgV0twed_V8E8l7kjJd882X6fEUE$

This just tests invalid metric format, right?

> 
> Intel don't have JSON encodings for the TSX events and so they use
> sysfs events and this is what motivated the has_event test:
> https://urldefense.com/v3/__https://lore.kernel.org/linux-perf-users/20230623151016.4193660-1-irogers@google.com/__;!!ACWV5N9M2RV99hQ!OKyD56aIReczgaPkGD3MZ0yZ-WFe7qXps1aFyF6pibEN8nk0r4N5Y87MgV0twed_V8E8l7kjJd88rRd1z5c$
> 
> Some other thoughts in this area:
> 1) I'd like to get sysfs snapshots so that we can get things like
> parse-events coverage of heterogeneous PMUs without needing such a
> system.

That idea would seem good to testing other sort of uncore PMUs - for 
example, since I don't have access to a system which supports sys 
events, I need to bodge the kernel to support some fake PMU kernel 
driver for things like smmu pmcg.

> 2) The largest part of the perf binary is the json data.

oh

> I'd like to
> convert the json data to a sysfs style, then compress it in a way
> where we benefit from duplication between files (zip can't do this,
> but tgz or 7zip can). libarchive can load these formats from memory.
> The current json data on x86 converts to about 7MB of read-only data,
> but the same json files compress down to about 1.5MB. The perf binary
> is about 3MB of code, so doing the compression should hopefully make
> the file size about half what it currently is and do something to stem
> the problem of the binary slowly growing over time with new
> architecture releases.

ok, sounds reasonable if slow binary loading is really a problem.

> 3) I'm hoping we can do something like a unionfs with the in memory
> sysfs, on disk sysfs tar balls and the like, and the machine's actual
> sysfs so that we can just have one consistent view in the tool.
> 4) I want to make PMUs lazier so that we don't need to eagerly load
> all the events. The cycles event doesn't need json or sysfs data, but
> it is all still loaded due to wanting the PMU. This faults in a lot of
> JSON data on x86 that is then never used.
> 
That should be pretty easy to do by only needing to setup event aliases 
et al when we have events which are not from known config terms, right?

Thanks,
John

Re: perf test pmu-events question

[Ian Rogers]

On Mon, Jun 26, 2023 at 6:33 AM John Garry <john.g.garry@oracle.com> wrote:
>
> On 23/06/2023 16:48, Ian Rogers wrote:
> > On Fri, Jun 23, 2023 at 8:20 AM John Garry <john.g.garry@oracle.com> wrote:
> >>
> >> Hi Ian,
> >>
> >> I was doing some re-write for pmu sys events metric support and I want
> >> to add more testcases - we don't really have any.
> >>
> >> So I noticed that tests/pmu-events.c::test__parsing() can pick up on an
> >> invalid metric for the test CPU, like M3 as it references itself.
> >> However we can't detect whether event aliases referenced in the metric
> >> exist for the CPU. Is it worth testing for this? Would it be sane to
> >> scan the associated CPU event tables to see if we can find the event
> >> there? Or do we already have some per-non-test-CPU metric validator
> >> already in the testcases (I could not see it)?
> >
>
> Hi Ian,
>
> Thanks for getting back to me.
>
> >
> > Hi John,
> >
> > we always need more tests :-)
>
> Sure
>
> > For Intel there has historically been a
> > problem that the names in metrics and the event data will get out of
> > alignment. There is a best effort test during the metric generation
> > that this doesn't happen any more here:
> > https://urldefense.com/v3/__https://github.com/intel/perfmon/blob/main/scripts/create_perf_json.py*L1171-L1188__;Iw!!ACWV5N9M2RV99hQ!OKyD56aIReczgaPkGD3MZ0yZ-WFe7qXps1aFyF6pibEN8nk0r4N5Y87MgV0twed_V8E8l7kjJd88_AjTGW8$
>
> Does that validate alias event support for the CPU? It seems that the
> specific lines mentioned are just checking for keywords.

So we filter out all of the keywords and then assert the named thing
is either an event or an auxiliary metric:
assert v in events or v.upper() in events or v in infoname or v in aux,

I agree, the weight of the code is toward skipping the keywords.

> > But still things get messed up, such as PMU names being mismatched -
> > when this happens the JSON events just don't appear at runtime. We
> > could try to replicate the event matching logic at creation time in
> > jevents.py and that should do what you mention and be
> > multi-architecture.
>
> OK, that could work. It is limited to testing just aliases, which I
> suppose has some value.

Note, I'm going to try avoid using the name aliases as it is
overloaded in the tool whereas we tend to just mean event. It is
likely the code/comments in the tool will slowly migrate to my
preference :-)

> However I am not sure how well this would suit testing sys event metric
> support, where I want to ensure that a specific event alias is chosen
> for a metric in the same pmu_sys_events struct.

Are you specifying the PMU? If not there is a danger the event will
match >1 PMU.

> > The metric test tests every metric produces an
> > output, and this fails when event parsing fails, so this has
> > traditionally been the way to find bad metrics.
> >We do have build time
> > tests like:
> > https://urldefense.com/v3/__https://git.kernel.org/pub/scm/linux/kernel/git/perf/perf-tools-next.git/tree/tools/perf/pmu-events/Build?h=perf-tools-next*n30__;Iw!!ACWV5N9M2RV99hQ!OKyD56aIReczgaPkGD3MZ0yZ-WFe7qXps1aFyF6pibEN8nk0r4N5Y87MgV0twed_V8E8l7kjJd882X6fEUE$
>
> This just tests invalid metric format, right?

So this specific test is checking the metric code passes some unit
tests. When we parse metrics from json, in jevents.py, we use this
code and it will throw exceptions if the json metric is badly formed.
You probably remember seeing patches fixes parentheses.

> >
> > Intel don't have JSON encodings for the TSX events and so they use
> > sysfs events and this is what motivated the has_event test:
> > https://urldefense.com/v3/__https://lore.kernel.org/linux-perf-users/20230623151016.4193660-1-irogers@google.com/__;!!ACWV5N9M2RV99hQ!OKyD56aIReczgaPkGD3MZ0yZ-WFe7qXps1aFyF6pibEN8nk0r4N5Y87MgV0twed_V8E8l7kjJd88rRd1z5c$
> >
> > Some other thoughts in this area:
> > 1) I'd like to get sysfs snapshots so that we can get things like
> > parse-events coverage of heterogeneous PMUs without needing such a
> > system.
>
> That idea would seem good to testing other sort of uncore PMUs - for
> example, since I don't have access to a system which supports sys
> events, I need to bodge the kernel to support some fake PMU kernel
> driver for things like smmu pmcg.

My thoughts too. I lack a lot of heterogeneous systems for testing.

> > 2) The largest part of the perf binary is the json data.
>
> oh
>
> > I'd like to
> > convert the json data to a sysfs style, then compress it in a way
> > where we benefit from duplication between files (zip can't do this,
> > but tgz or 7zip can). libarchive can load these formats from memory.
> > The current json data on x86 converts to about 7MB of read-only data,
> > but the same json files compress down to about 1.5MB. The perf binary
> > is about 3MB of code, so doing the compression should hopefully make
> > the file size about half what it currently is and do something to stem
> > the problem of the binary slowly growing over time with new
> > architecture releases.
>
> ok, sounds reasonable if slow binary loading is really a problem.

The time for perf to parse events I will probably regress with
compression, because of the need to decompress. The file size is an
issue that comes up when the binary is installed at the scale Google
does (both devices and data centers). We're over 10MB and edging
slowly toward 11MB as Intel add models.

> > 3) I'm hoping we can do something like a unionfs with the in memory
> > sysfs, on disk sysfs tar balls and the like, and the machine's actual
> > sysfs so that we can just have one consistent view in the tool.
> > 4) I want to make PMUs lazier so that we don't need to eagerly load
> > all the events. The cycles event doesn't need json or sysfs data, but
> > it is all still loaded due to wanting the PMU. This faults in a lot of
> > JSON data on x86 that is then never used.
> >
> That should be pretty easy to do by only needing to setup event aliases
> et al when we have events which are not from known config terms, right?

Yeah, it feels low hanging. The code turns every json event and sysfs
event into a perf_pmu_alias when the PMU is created, the events are
sorted and then we search them at parse time. We can avoid doing this
and search the jevents.py created tables instead. This should turn
loading n events into log2(n) for the sake of the search. This will
change with the compressed version, and the behavior will depend on
the compression format. This is why I like the idea of punting the
problem to libarchive.

Thanks,
Ian

> Thanks,
> John

Re: perf test pmu-events question

[John Garry]

> 
>>> But still things get messed up, such as PMU names being mismatched -
>>> when this happens the JSON events just don't appear at runtime. We
>>> could try to replicate the event matching logic at creation time in
>>> jevents.py and that should do what you mention and be
>>> multi-architecture.
>>
>> OK, that could work. It is limited to testing just aliases, which I
>> suppose has some value.
> 
> Note, I'm going to try avoid using the name aliases as it is
> overloaded in the tool whereas we tend to just mean event. It is
> likely the code/comments in the tool will slowly migrate to my
> preference :-)
> 
>> However I am not sure how well this would suit testing sys event metric
>> support, where I want to ensure that a specific event alias is chosen
>> for a metric in the same pmu_sys_events struct.
> 
> Are you specifying the PMU?

We specify the event, which obviously includes the PMU "unit" and 
"compat", which we can match against. When all the events match in the 
metric expr, then we know the metric is supported in the system.

I may send this series as an RFC and maybe you can kindly suggest what 
testcases to add ...

> If not there is a danger the event will
> match >1 PMU.

Do you mean match 1> homogeneous PMU? Or events for heterogeneous PMUs 
may clash?

If the former, then this is ok. If the latter, then this is always a 
problem.

> 
>>> The metric test tests every metric produces an
>>> output, and this fails when event parsing fails, so this has
>>> traditionally been the way to find bad metrics.
>>> We do have build time
>>> tests like:
>>> https://urldefense.com/v3/__https://git.kernel.org/pub/scm/linux/kernel/git/perf/perf-tools-next.git/tree/tools/perf/pmu-events/Build?h=perf-tools-next*n30__;Iw!!ACWV5N9M2RV99hQ!OKyD56aIReczgaPkGD3MZ0yZ-WFe7qXps1aFyF6pibEN8nk0r4N5Y87MgV0twed_V8E8l7kjJd882X6fEUE$
>>
>> This just tests invalid metric format, right?
> 
> So this specific test is checking the metric code passes some unit
> tests. When we parse metrics from json, in jevents.py, we use this
> code and it will throw exceptions if the json metric is badly formed.
> You probably remember seeing patches fixes parentheses.

yes...

> 
>>>
>>> Intel don't have JSON encodings for the TSX events and so they use
>>> sysfs events and this is what motivated the has_event test:
>>> https://urldefense.com/v3/__https://lore.kernel.org/linux-perf-users/20230623151016.4193660-1-irogers@google.com/__;!!ACWV5N9M2RV99hQ!OKyD56aIReczgaPkGD3MZ0yZ-WFe7qXps1aFyF6pibEN8nk0r4N5Y87MgV0twed_V8E8l7kjJd88rRd1z5c$
>>>
>>> Some other thoughts in this area:
>>> 1) I'd like to get sysfs snapshots so that we can get things like
>>> parse-events coverage of heterogeneous PMUs without needing such a
>>> system.
>>
>> That idea would seem good to testing other sort of uncore PMUs - for
>> example, since I don't have access to a system which supports sys
>> events, I need to bodge the kernel to support some fake PMU kernel
>> driver for things like smmu pmcg.
> 
> My thoughts too. I lack a lot of heterogeneous systems for testing.
> 
>>> 2) The largest part of the perf binary is the json data.
>>
>> oh
>>
>>> I'd like to
>>> convert the json data to a sysfs style, then compress it in a way
>>> where we benefit from duplication between files (zip can't do this,
>>> but tgz or 7zip can). libarchive can load these formats from memory.
>>> The current json data on x86 converts to about 7MB of read-only data,
>>> but the same json files compress down to about 1.5MB. The perf binary
>>> is about 3MB of code, so doing the compression should hopefully make
>>> the file size about half what it currently is and do something to stem
>>> the problem of the binary slowly growing over time with new
>>> architecture releases.
>>
>> ok, sounds reasonable if slow binary loading is really a problem.
> 
> The time for perf to parse events I will probably regress with
> compression, because of the need to decompress. The file size is an
> issue that comes up when the binary is installed at the scale Google
> does (both devices and data centers). We're over 10MB and edging
> slowly toward 11MB as Intel add models.

ok

> 
>>> 3) I'm hoping we can do something like a unionfs with the in memory
>>> sysfs, on disk sysfs tar balls and the like, and the machine's actual
>>> sysfs so that we can just have one consistent view in the tool.
>>> 4) I want to make PMUs lazier so that we don't need to eagerly load
>>> all the events. The cycles event doesn't need json or sysfs data, but
>>> it is all still loaded due to wanting the PMU. This faults in a lot of
>>> JSON data on x86 that is then never used.
>>>
>> That should be pretty easy to do by only needing to setup event aliases
>> et al when we have events which are not from known config terms, right?
> 
> Yeah, it feels low hanging. The code turns every json event and sysfs
> event into a perf_pmu_alias when the PMU is created, the events are
> sorted and then we search them at parse time. We can avoid doing this
> and search the jevents.py created tables instead. This should turn
> loading n events into log2(n) for the sake of the search. This will
> change with the compressed version, and the behavior will depend on
> the compression format. This is why I like the idea of punting the
> problem to libarchive.
> 

ok

Thanks,
John

Re: perf test pmu-events question

[Ian Rogers]

On Mon, Jun 26, 2023 at 10:49 AM John Garry <john.g.garry@oracle.com> wrote:
>
> >
> >>> But still things get messed up, such as PMU names being mismatched -
> >>> when this happens the JSON events just don't appear at runtime. We
> >>> could try to replicate the event matching logic at creation time in
> >>> jevents.py and that should do what you mention and be
> >>> multi-architecture.
> >>
> >> OK, that could work. It is limited to testing just aliases, which I
> >> suppose has some value.
> >
> > Note, I'm going to try avoid using the name aliases as it is
> > overloaded in the tool whereas we tend to just mean event. It is
> > likely the code/comments in the tool will slowly migrate to my
> > preference :-)
> >
> >> However I am not sure how well this would suit testing sys event metric
> >> support, where I want to ensure that a specific event alias is chosen
> >> for a metric in the same pmu_sys_events struct.
> >
> > Are you specifying the PMU?
>
> We specify the event, which obviously includes the PMU "unit" and
> "compat", which we can match against. When all the events match in the
> metric expr, then we know the metric is supported in the system.

So when an event is specified then we end up in this code:
https://git.kernel.org/pub/scm/linux/kernel/git/perf/perf-tools-next.git/tree/tools/perf/util/parse-events.y?h=perf-tools-next#n335
that is we take the event name, add it to a term list, then try adding
the event (as a term) to every PMU. Were the same event to be on >1
PMU then we'd open an event for each PMU. We use this for opening
uncore and hybrid (multiple heterogeneous PMUs) events.

> I may send this series as an RFC and maybe you can kindly suggest what
> testcases to add ...

sure :-)

> > If not there is a danger the event will
> > match >1 PMU.
>
> Do you mean match 1> homogeneous PMU? Or events for heterogeneous PMUs
> may clash?
>
> If the former, then this is ok. If the latter, then this is always a
> problem.

So because the event is opened on every PMU, there could conceivably
be a PMU with the same named event and this may break the metric. We
do this all the time for Intel, so the danger isn't so great.

We should probably make cases like:
..
MetricName: "IPC",
MetrcExpr: "instructions / cycles",
..
work for heterogeneous systems (we don't currently match legacy
instructions and cycles events on anything other than core PMUs). I
believe the example above would open events like:
{pmu1/cycles/,pmu1/instructions/},{pmu2/cycles/,pmu2/instructions/}
but when we do the metric set up we'll only look at the first group of
events. For Intel hybrid metrics we're avoiding this by duplicating
metrics and each metric specifies the PMU with the event.

Anyway, looking forward to the RFC. Thanks,
Ian

> >
> >>> The metric test tests every metric produces an
> >>> output, and this fails when event parsing fails, so this has
> >>> traditionally been the way to find bad metrics.
> >>> We do have build time
> >>> tests like:
> >>> https://urldefense.com/v3/__https://git.kernel.org/pub/scm/linux/kernel/git/perf/perf-tools-next.git/tree/tools/perf/pmu-events/Build?h=perf-tools-next*n30__;Iw!!ACWV5N9M2RV99hQ!OKyD56aIReczgaPkGD3MZ0yZ-WFe7qXps1aFyF6pibEN8nk0r4N5Y87MgV0twed_V8E8l7kjJd882X6fEUE$
> >>
> >> This just tests invalid metric format, right?
> >
> > So this specific test is checking the metric code passes some unit
> > tests. When we parse metrics from json, in jevents.py, we use this
> > code and it will throw exceptions if the json metric is badly formed.
> > You probably remember seeing patches fixes parentheses.
>
> yes...
>
> >
> >>>
> >>> Intel don't have JSON encodings for the TSX events and so they use
> >>> sysfs events and this is what motivated the has_event test:
> >>> https://urldefense.com/v3/__https://lore.kernel.org/linux-perf-users/20230623151016.4193660-1-irogers@google.com/__;!!ACWV5N9M2RV99hQ!OKyD56aIReczgaPkGD3MZ0yZ-WFe7qXps1aFyF6pibEN8nk0r4N5Y87MgV0twed_V8E8l7kjJd88rRd1z5c$
> >>>
> >>> Some other thoughts in this area:
> >>> 1) I'd like to get sysfs snapshots so that we can get things like
> >>> parse-events coverage of heterogeneous PMUs without needing such a
> >>> system.
> >>
> >> That idea would seem good to testing other sort of uncore PMUs - for
> >> example, since I don't have access to a system which supports sys
> >> events, I need to bodge the kernel to support some fake PMU kernel
> >> driver for things like smmu pmcg.
> >
> > My thoughts too. I lack a lot of heterogeneous systems for testing.
> >
> >>> 2) The largest part of the perf binary is the json data.
> >>
> >> oh
> >>
> >>> I'd like to
> >>> convert the json data to a sysfs style, then compress it in a way
> >>> where we benefit from duplication between files (zip can't do this,
> >>> but tgz or 7zip can). libarchive can load these formats from memory.
> >>> The current json data on x86 converts to about 7MB of read-only data,
> >>> but the same json files compress down to about 1.5MB. The perf binary
> >>> is about 3MB of code, so doing the compression should hopefully make
> >>> the file size about half what it currently is and do something to stem
> >>> the problem of the binary slowly growing over time with new
> >>> architecture releases.
> >>
> >> ok, sounds reasonable if slow binary loading is really a problem.
> >
> > The time for perf to parse events I will probably regress with
> > compression, because of the need to decompress. The file size is an
> > issue that comes up when the binary is installed at the scale Google
> > does (both devices and data centers). We're over 10MB and edging
> > slowly toward 11MB as Intel add models.
>
> ok
>
> >
> >>> 3) I'm hoping we can do something like a unionfs with the in memory
> >>> sysfs, on disk sysfs tar balls and the like, and the machine's actual
> >>> sysfs so that we can just have one consistent view in the tool.
> >>> 4) I want to make PMUs lazier so that we don't need to eagerly load
> >>> all the events. The cycles event doesn't need json or sysfs data, but
> >>> it is all still loaded due to wanting the PMU. This faults in a lot of
> >>> JSON data on x86 that is then never used.
> >>>
> >> That should be pretty easy to do by only needing to setup event aliases
> >> et al when we have events which are not from known config terms, right?
> >
> > Yeah, it feels low hanging. The code turns every json event and sysfs
> > event into a perf_pmu_alias when the PMU is created, the events are
> > sorted and then we search them at parse time. We can avoid doing this
> > and search the jevents.py created tables instead. This should turn
> > loading n events into log2(n) for the sake of the search. This will
> > change with the compressed version, and the behavior will depend on
> > the compression format. This is why I like the idea of punting the
> > problem to libarchive.
> >
>
> ok
>
> Thanks,
> John
>