https://jira.whamcloud.com This file is an XML representation of an issue en-us 9.4.14 940014 05-12-2023 https://jira.whamcloud.com/browse/LU-3992 Lustre <p>Kernel commit c1c3443c9c5e9be92641029ed229a41563e44506<br/> assigns all allowed cpus to emulated node.</p> LU-3992

Fix NUMA emulated mode

Bug Minor Resolved Fixed Liang Zhen Andriy Skulysh patch Mon, 23 Sep 2013 06:28:53 +0000 Thu, 29 May 2014 13:57:55 +0000 Mon, 18 Nov 2013 13:10:02 +0000 Lustre 2.6.0 Lustre 2.5.2 0 8 <p>patch: <a href="http://review.whamcloud.com/7724" class="external-link" target="_blank" rel="nofollow noopener">http://review.whamcloud.com/7724</a></p> <p>without the fix insmod libcfs.ko fails with numa=fake=16 in kernel boot cmdline. </p> <div class="preformatted panel" style="border-width: 1px;"><div class="preformattedContent panelContent"> <pre> LNetError: 4055:0:(linux-cpu.c:881:cfs_cpt_table_create()) Failed to setup CPU-partition-table with 4 CPU-partitions, online HW nodes: 16, HW cpus: 32. LNetError: 4055:0:(linux-cpu.c:1093:cfs_cpu_init()) Failed to create ptable with npartitions 0 </pre> </div></div> <p>sorry I failed to understand how this can happen, could you give an example of this?</p> <p>each emulated node has all cpus in cpumask (cpumask_of_node()).<br/> So each cpu exists in each node's mask <br/> We need to stop loop when all cpus are assigned. It doesn't matter which cpu is chosen for node.</p> <p>I think module parameter cpu_pattern can work around this, would it be OK if you just use this parameter instead of adding a patch? I'd like user to see these errors when situation like this happened.</p> <p>ncpt is always &gt; 0 and we do only cpt++, so "if" can be only "=="<br/> What errors can be here ? Only with strange cfs_node_to_cpumask() like in emulated NUMA case.<br/> Resulting topology can be easily examined via /proc/sys/lnet/cpu_partition_table.<br/> Is new parameter really needed ? We will force user to create dummy cpu_pattern.</p> <p>We run into this problem and with the patch it works fine for us. I think at least the user/admin prefer a fix instead of using cpu_pattern as a workaround. Is there a probelm with the fix?</p> <p>Is there any concern or 'side effect' for the fix? We'd like to adopt the fix over the cpu-pattern workaround.</p> <p>OK, I think it should be fine</p> <p>Landed for 2.6</p> Development Rank 1|hzw3mn: Rank (Obsolete) 10675 Severity