Thread (19 messages) 19 messages, 2 authors, 2014-10-11

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

From: Tadeusz Struk <hidden>
Date: 2014-10-09 16:16:37

On 10/09/2014 04:23 AM, Prarit Bhargava wrote:
quoted
  int numa_node; /* NUMA node this device is close to */
quoted
...
That's just bad english.  The numa node value (for pci devices) is
read from the ACPI tables on the system and represents the node that
the pci_dev is connected to.
quoted
quoted
};

In case when there are two nodes and only node 0 has memory,
dev->numa_node will be 0 even though the device will be connected to the
pci root port of node 1.
Your calculation completely falls apart and returns incorrect values when
cpu hotplug is used or if there are multi-socket nodes (as was the case
on the system that panicked), or if one uses the new cluster-on-die mode.
This calculation is sole for multi-socket configuration. This is why is
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;
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.
This patch will make sure that this will not happen and that the
configuration will be optimal.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help