Re: [PATCH 2/2] crypto: qat - Enforce valid numa configuration.

On 10/09/2014 10:32 AM, Prarit Bhargava wrote:

quoted

This calculation is sole for multi-socket configuration. This is why is

quoted

was introduced and what it was tested for.
There is no point discussing NUMA for single-socket configuration.
Single socket configurations are not NUMA. In this case dev->numa_node
is usually equal to NUMA_NO_NODE (-1) and adf_get_dev_node_id(pdev) will
always return 0;

The fact that you return an incorrect value here for any configuration is simply
put, bad.  You shouldn't do that.

Well I wouldn't say it is incorrect. adf_get_dev_node_id() returns the
phys proc id the dev is connected to, so in single socket configuration
there is only one socket 0.

quoted

quoted

Please confirm that, but I think the system it panicked on was a two
sockets system with only node 0 populated with memory and accelerator
plugged it to node 1 (phys_proc_id == 1).
In this case adf_get_dev_node_id(pdev) returned 1 and this was passed to
kzalloc_node(size, GFP_KERNEL, 1) and because there was no memory on
node 1 kzalloc_node() panicked.

Yep; but my interpretation was that node 1 didn't exist at all and it panicked.

Why didn't exist? The fact that there was no memory on node 1 doesn't
make it disappear. There are two sockets in the platform 0 & 1 even
though only one (node 0) has memory. The only problem with that is - it
is far from optimal if device connected to node 1 uses memory on node 0.
And this is what would happen if we would use dev_to_node(dev) here.

quoted

quoted

This patch will make sure that this will not happen and that the
configuration will be optimal.

Yep, it will.  But what about cpu hotplug?

I don't think cpu hotplug matters here. This is one (probe) time
determination if the configuration is optimal or not and if it makes
sense to use this accelerator or not.