<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=us-ascii">
<meta name="Generator" content="Microsoft Word 14 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
margin-bottom:.0001pt;
font-size:11.0pt;
font-family:"Calibri","sans-serif";}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:purple;
text-decoration:underline;}
span.EmailStyle17
{mso-style-type:personal-compose;
font-family:"Arial","sans-serif";
color:windowtext;}
.MsoChpDefault
{mso-style-type:export-only;
font-family:"Calibri","sans-serif";}
@page WordSection1
{size:8.5in 11.0in;
margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
</head>
<body lang="EN-US" link="blue" vlink="purple">
<style type="text/css" style="display:none;"><!-- P {margin-top:0;margin-bottom:0;} --></style>
<div id="divtagdefaultwrapper" style="font-size:12pt;color:#000000;font-family:Calibri,Arial,Helvetica,sans-serif;" dir="ltr">
<p>Andrew,</p>
<p><br>
</p>
<p>Are they really just not working? I didn't see that with KNL (the default CPT generated without the fixes from LU-8703 is very weird, but didn't affect performance much - the real NUMA-ness of KNL processors seems to be minimal, despite the various NUMA
related configuration options...), but Cray systems are unusual and I don't think I ever saw an empty NUMA node (possibly something we fix in the BIOS). Anyway, you should be able to work around this without patching your client, just set some module parameters
before starting Lustre/loading the modules.</p>
<p></p>
<div><br>
</div>
<div>I can think of two things which should work, both are module parameters for the libcfs module, I believe. I haven't tried this, so it's possible your error is coming earlier in the loading process... But I think not, based on the message.</div>
<div><br>
</div>
<div>1. Limit yourself to 1 partition, by setting cpu_npartitions to 1.</div>
<div>static int cpu_npartitions;</div>
<div>module_param(cpu_npartitions, int, 0444);</div>
<div>MODULE_PARM_DESC(cpu_npartitions, "# of CPU partitions");</div>
<br>
<p></p>
<p>2. Or, you could draw up a CPU partition table yourself. Parameter name is cpu_pattern.</p>
<p></p>
<p><br>
</p>
<p>Here's the code describing that:<br>
"</p>
<div>/**</div>
<div> * modparam for setting CPU partitions patterns:</div>
<div> *</div>
<div> * i.e: "0[0,1,2,3] 1[4,5,6,7]", number before bracket is CPU partition ID,</div>
<div> * number in bracket is processor ID (core or HT)</div>
<div> *</div>
<div> * i.e: "N 0[0,1] 1[2,3]" the first character 'N' means numbers in bracket</div>
<div> * are NUMA node ID, number before bracket is CPU partition ID.</div>
<div> *</div>
<div> * i.e: "N", shortcut expression to create CPT from NUMA & CPU topology</div>
<div> *</div>
<div> * NB: If user specified cpu_pattern, cpu_npartitions will be ignored</div>
<div> */</div>
<div>static char *cpu_pattern = "N";</div>
<div>module_param(cpu_pattern, charp, 0444);</div>
<div>MODULE_PARM_DESC(cpu_pattern, "CPU partitions pattern");"</div>
<div><br>
</div>
<div>Notice the default pattern is N, but you can override it.</div>
<div><br>
</div>
<div>(Code references from <span>libcfs/libcfs/linux/linux-cpu.c in Lustre.)</span></div>
<div></div>
<div><br>
</div>
<div>Either of those should let you get past the error, no need to carry patches. I can't speak to the production-readiness of the patches, but I'd definitely go the module parameter route if it were my system.</div>
<div><br>
</div>
<div>- Patrick</div>
<p></p>
</div>
<hr style="display:inline-block;width:98%" tabindex="-1">
<div id="divRplyFwdMsg" dir="ltr"><font face="Calibri, sans-serif" style="font-size:11pt" color="#000000"><b>From:</b> lustre-discuss <lustre-discuss-bounces@lists.lustre.org> on behalf of Prout, Andrew - LLSC - MITLL <aprout@ll.mit.edu><br>
<b>Sent:</b> Wednesday, February 1, 2017 3:11:07 PM<br>
<b>To:</b> lustre-discuss@lists.lustre.org<br>
<b>Subject:</b> [lustre-discuss] Status of LU-8703 for Knights Landing</font>
<div> </div>
</div>
<div>
<div class="WordSection1">
<p class="MsoNormal"><span style="font-size:10.0pt;font-family:"Arial","sans-serif"">Anyone know the production-readiness of the patches attached to LU-8703 to fix issues with Lustre on Xeon Phi Knights Landing hardware? We’re considering merging them against
our 2.9.0 client to get it working on our KL nodes.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:10.0pt;font-family:"Arial","sans-serif""><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:10.0pt;font-family:"Arial","sans-serif"">Andrew Prout<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:10.0pt;font-family:"Arial","sans-serif"">Lincoln Laboratory Supercomputing Center<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:10.0pt;font-family:"Arial","sans-serif"">MIT Lincoln Laboratory<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:10.0pt;font-family:"Arial","sans-serif"">244 Wood Street, Lexington, MA 02420<o:p></o:p></span></p>
</div>
</div>
</body>
</html>