linux-kernel - Re: [PATCHv2 2/3] cpupower: mperf_monitor: Introduce per_cpu

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Mon, 28 Oct 2019 16:37:01 +0000
From:   "Natarajan, Janakarajan" <Janakarajan.Natarajan@....com>
To:     shuah <shuah@...nel.org>, Thomas Renninger <trenn@...e.com>
CC:     "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "linux-pm@...r.kernel.org" <linux-pm@...r.kernel.org>,
        Pu Wen <puwen@...on.com>, Thomas Gleixner <tglx@...utronix.de>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Kate Stewart <kstewart@...uxfoundation.org>,
        Allison Randal <allison@...utok.net>,
        Richard Fontana <rfontana@...hat.com>,
        Borislav Petkov <bp@...e.de>
Subject: Re: [PATCHv2 2/3] cpupower: mperf_monitor: Introduce per_cpu_schedule
 flag

On 10/25/2019 10:33 AM, shuah wrote:
> 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?


Sure. I can send out a patch capturing these ideas.


-Janak


>
> thanks,
> -- Shuah
>