On 02/13/2018 08:08 AM, Jiri Olsa wrote:
On Mon, Feb 12, 2018 at 02:22:30PM -0800, Raghavendra Rao Ananta wrote:


On 02/12/2018 01:21 PM, Jiri Olsa wrote:
On Mon, Feb 12, 2018 at 10:04:42PM +0100, Jiri Olsa wrote:
On Mon, Feb 12, 2018 at 09:42:05AM -0800, Raghavendra Rao Ananta wrote:
Hi Jiri,

Thank you for the response.

Does perf tool has its own check to see if the CPU was offline during the
lifetime of an event? If so, it might ignore these type of events.

nope, we don't check on that


Initially, I tested the same using perf tool and found similar results.
Then I debugged further and found that the perf core was actually sending
data to the userspace (copy_to_user()) and the corresponding count for the
data. Hence, I tested this further by writing my own userspace application,
and I was able to read the count through this,
even when the CPU was made offline and back online.

Do you think we also have to modify the perf tool accordingly?

hum, I wonder what's wrong.. will check

I think the user space needs to enable the event once the
cpu gets online.. which we dont do and your app does..?

maybe we could add perf_event_attr::enable_on_online ;-)

I'll check what we can do in user space, I guess we can
monitor the cpu state and enable event accordingly

jirka

Yes, probably that's the reason.

In order for an event to get scheduled-in, it expects the event to be at
least in PERF_EVENT_STATE_INACTIVE state. If you notice, in my patch,
when the cpu wakes up, we are initializing the state of the event
(perf_event__state_init()) and then trying to schedule-in. Since the event
was created with a disabled state, it seems that the same this is followed
and the state gets initialized to PERF_EVENT_STATE_OFF. Unfortunately,
events in this state could not be scheduled.

One way for things to get working is, instead of calling
perf_event__state_init() before the event is scheduled-in (when the cpu
wakes up), we can do something like:
perf_event_set_state(event, PERF_EVENT_STATE_INACTIVE);

could you add check in ioctl call that set the inactive state
on the dormant event.. that would start it once the cpu is
online.. as requested

I am a little confused. When you say "check", do you mean a new ioctl command?

So the flow (from the user-space perspective) would go something like this?

1. // CPU offline

2. perf_event_open(); // event started as disabled --> added to dormant list in the kernel

3. ioctl(SET_INACTIVE); // change the state of the event to inactive

4. // CPU woken up!

5. // schedule the (inactive) event by traversing the dormant list

Is this what you were trying to mention, or am I missing something?

Raghavendra
--
Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project

Reply via email to