one_cpu() doesn't seem to work, for me at least

[itamarst]

Not sure if this is a hardware issue or a software bug or user error.

Example:

#[test]
    fn one_cpu() {
        let mut group = Group::new().unwrap();
        let _cycles = group
            .add(&Builder::new(Hardware::CPU_CYCLES).one_cpu(0))
            .unwrap();
    }

When run:

called `Result::unwrap()` on an `Err` value: Os { code: 22, kind: InvalidInput, message: "Invalid argument" }

Linux 6.18.7, Intel i7-12700K CPU, perf-event2 0.7.4.

Thanks for maintaining this!

[samp5]

I believe this is because of how this crate currently constructs Groups and the restrictions of grouped event targets.

In the doc comment above Group::new() it specifies that the resulting group is only suitable for observing the current process on any CPU. By restricting the CPU of a member counter, I believe the kernel will reject the combination.

More from the perf_event_open man page: "An event group is scheduled onto the CPU as a unit: it will be put onto the CPU only if all of the events in the group can be put onto the CPU."

The builder API being less than ergonomic was discussed in #64, and this seems like another symptom of that.

[itamarst]

Another thing I've noted, perhaps related, perhaps not, is that setting CPU affinity results in cpu instruction count counter returning 0. (Although it's possible I only discovered this when using the original perf-event, so would require a reproducer...)

[samp5]

I think that is because your measured process is not being scheduled on the core specified in your builder config?

I also see zero if I don't restrict the affinity of the process. Running the process with taskset --cpu-list 0 <prog> limits the cores the process is eligible to run on and I saw non-zero results.