Thread (11 messages) 11 messages, 3 authors, 2021-05-28

Re: [RFC v2 4/4] powerpc/papr_scm: Add cpu hotplug support for nvdimm pmu device

From: kajoljain <hidden>
Date: 2021-05-26 09:08:50
Also in: lkml


On 5/26/21 2:15 PM, Aneesh Kumar K.V wrote:
On 5/26/21 12:56 PM, kajoljain wrote:
quoted

On 5/25/21 7:46 PM, Peter Zijlstra wrote:
quoted
On Tue, May 25, 2021 at 06:52:16PM +0530, Kajol Jain wrote:
quoted
Patch here adds cpu hotplug functions to nvdimm pmu.
I'm thinking "Patch here" qualifies for "This patch", see
Documentation/process/submitting-patches.rst .
Hi Peter,
    I will reword this commit message.
quoted
quoted
It adds cpumask to designate a cpu to make HCALL to
collect the counter data for the nvdimm device and
update ABI documentation accordingly.

Result in power9 lpar system:
command:# cat /sys/devices/nmem0/cpumask
0
Is this specific to the papr thing, or should this be in generic nvdimm
code?
This code is not specific to papr device and we can move it to
generic nvdimm interface. But do we need to add some checks on whether
any arch/platform specific driver want that support or we can assume
that this will be something needed by all platforms?
It says the cpu that should be used to make the hcall. That makes it PAPR specific.
Hi Aneesh,
  The hcall in the commit message basically pointing to the method we used to get
counter data. But adding cpumask to a PMU is not specific to powerpc.
So, Incase other platform/arch want to enable hotplug feature, they can use same code for
that and hence we can move it to generic nvdimm interface.

Our concerned it mainly about is it right to assume from the common code point of view, if
the cpumask attr is null, common code can add the cpumask support to it, or 
do we need to have explicit flag for the device to request for it.

Thanks,
Kajol Jain
-aneesh
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help