On 10/09/2014 10:32 AM, Prarit Bhargava wrote: >> 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; > 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. > >> > 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. > >> > 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. -- To unsubscribe from this list: send the line "unsubscribe linux-crypto" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
