Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
Subject: Re: [PATCHv2 2/3] cpupower: mperf_monitor: Introduce per_cpu_schedule
 flag
To:     Thomas Renninger <trenn@suse.com>,
        "Natarajan, Janakarajan" <Janakarajan.Natarajan@amd.com>
Cc:     "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
        "linux-pm@vger.kernel.org" <linux-pm@vger.kernel.org>,
        Pu Wen <puwen@hygon.com>, Thomas Gleixner <tglx@linutronix.de>,
        Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
        Kate Stewart <kstewart@linuxfoundation.org>,
        Allison Randal <allison@lohutok.net>,
        Richard Fontana <rfontana@redhat.com>,
        Borislav Petkov <bp@suse.de>, shuah <shuah@kernel.org>
References: <cover.1570819652.git.Janakarajan.Natarajan@amd.com>
 <bb4b0e4137b62651b9d028925fa8f09ca5fbd989.1570819652.git.Janakarajan.Natarajan@amd.com>
 <24194241.SRZ5kbjNg7@skinner.arch.suse.de>
From:   shuah <shuah@kernel.org>
Message-ID: <e5c0ed24-6b2f-ea2f-6ce1-533f3727cb17@kernel.org>
Date:   Fri, 25 Oct 2019 09:33:39 -0600
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101
 Thunderbird/60.9.0
MIME-Version: 1.0
In-Reply-To: <24194241.SRZ5kbjNg7@skinner.arch.suse.de>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

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