Messages in this thread | | | Subject | Re: [PATCHv2 2/3] cpupower: mperf_monitor: Introduce per_cpu_schedule flag | From | shuah <> | Date | Fri, 25 Oct 2019 09:33:39 -0600 |
| |
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
| |