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-1164 Lustre <p>Hi,</p> <p>We believe that it could be a nice feature to be able control the number of kib scheduler threads launched by the ko2iblnd module.<br/> Indeed, we can have some situations where the default threads number is not appropriate. In the current code it creates as many threads as the number of CPU cores, which means 32 or even 40 on our MESCA platform. We have noticed a performance penalty when running so many kib scheduler threads.</p> <p>This is why I propose a patch that gives the ability to choose the number of kib scheduler threads. This is done via a ko2iblnd kernel module option. The default value remains unchanged.</p> <p>Cheers,<br/> Sebastien.</p> LU-1164

ko2iblnd schedulers

Improvement Minor Resolved Fixed Liang Zhen Sebastien Buisson Fri, 2 Mar 2012 08:26:24 +0000 Sun, 15 Sep 2013 08:04:47 +0000 Sun, 15 Sep 2013 08:04:47 +0000 Lustre 2.1.3 0 4 <p>Sebastien, yes indeed, I've put this on my radar for a while, we created way too many LND threads especially on those machines with tens of cores and HT. I will have a long term solution in 2.3, and will consider about have a short term fix for this.</p> <p>Hi,</p> <p>I have uploaded the patch at:</p> <p><a href="http://review.whamcloud.com/2246" class="external-link" target="_blank" rel="nofollow noopener">http://review.whamcloud.com/2246</a></p> <p>Sebastien,<br/> thank you for the patch. Having a tunable is a good start, but even better would be if this is auto tuning/limiting in some way. When there are so many cores, is it enough to have one thread per socket? One or two threads per interface?</p> <p>By having the default values be better, and a tunable to override this value, it is easier for users to get a good experience with Lustre out of the box, instead of having to tune dozens of parameters.</p> <p>Andreas, I will have a long term fix for this in project Apus (SMP node affinity)</p> <p>Hi,</p> <p>As Liang explained, the same thing has been done in a large set of patches bringing SMP scalability to master. So I understand it will not be possible to port it to former branches.</p> <p>For that purpose, I have created a b2_1 version of my patch accessible here:<br/> <a href="http://review.whamcloud.com/#change,3047" class="external-link" target="_blank" rel="nofollow noopener">http://review.whamcloud.com/#change,3047</a><br/> and also a b2_2 version here:<br/> <a href="http://review.whamcloud.com/#change,3044" class="external-link" target="_blank" rel="nofollow noopener">http://review.whamcloud.com/#change,3044</a></p> <p>It it possible to have them reviewed?</p> <p>Thanks,<br/> Sebastien.</p> <p>Patch is in 2.1, 2,3 and later have different solution</p> Development Rank 1|hzva1j: Rank (Obsolete) 5161