Re: [PATCHv2 2/3] cpupower: mperf_monitor: Introduce per_cpu_schedule flag

From: shuah
Date: Fri Oct 25 2019 - 11:33:43 EST


On 10/25/19 4:39 AM, Thomas Renninger wrote:
Hi Natarajan,

sorry for answering that late.
I post on top as it doesn't fit to the patch context:

While I like the 2 other patches, especially the first preparing for
a generic "ensure to always run on the measured CPU at measure time"
interface..., this patch does make use of it in a very static manner.

I then tried to get this more generic..., without any outcome for now.

If someone likes to play with this, my idea would be:

- the monitors need cpu_start() and cpu_stop() callbacks to register
- either start(), stop() and/or cpu_start(), cpu_stop() callbacks have to
be provided by a monitor.
- current behavior is only start/stop which means the whole per_cpu logic
resides inside the monitor
- if cpu_start/cpu_stop is provided, iterating over all cpus is done in
fork_it and general start/stop functions are an optionally entry point
before and after the per_cpu calls.

Then the cpu binding can be done from outside.
Another enhancement could be then to fork as many processes as there are CPUs
in case of per_cpu_schedule (or an extra param/flag) and then:

- Bind these forked processes to each cpu.
- Execute start measures via the forked processes on each cpu
- Execute test executable (which runs in yet another fork as done already)
- Execute stop measures via the forked processes on each cpu

This should be ideal environment to not interfere with the tested executable.
It would also allow a nicer program structure.


It will be good to capture these ideas in the ToDo file.

Natarajan! WOuld you like to send a patch updating the ToDo file with
these ideas?

thanks,
-- Shuah