lkml.org 
[lkml]   [2019]   [Oct]   [25]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: [PATCHv2 2/3] cpupower: mperf_monitor: Introduce per_cpu_schedule flag
From
Date
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

\
 
 \ /
  Last update: 2019-10-25 17:33    [W:0.080 / U:0.064 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site