<html 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=utf-8">
<meta name="Generator" content="Microsoft Word 15 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@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:0cm;
font-size:11.0pt;
font-family:"Calibri",sans-serif;}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
span.apple-converted-space
{mso-style-name:apple-converted-space;}
.MsoChpDefault
{mso-style-type:export-only;
font-size:10.0pt;}
@page WordSection1
{size:612.0pt 792.0pt;
margin:70.85pt 70.85pt 70.85pt 70.85pt;}
div.WordSection1
{page:WordSection1;}
--></style>
</head>
<body lang="FR" link="blue" vlink="purple" style="word-wrap:break-word">
<div class="WordSection1">
<p class="MsoNormal"><span lang="EN-US" style="mso-fareast-language:EN-US">I can’t see how stop-the-world effect can be avoided once all your carriers are busy with non-switchable CPU-bound tasks. Maybe I’m missing something
</span><span lang="EN-US" style="font-family:"Apple Color Emoji";mso-fareast-language:EN-US">😊</span><span lang="EN-US" style="mso-fareast-language:EN-US"><o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="mso-fareast-language:EN-US">Not very different from other pinning problems (JNI...), except the argument that 100% CPU usage should never occur so not a problem.<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="mso-fareast-language:EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="mso-fareast-language:EN-US">I will try to make some test to simulate and post the result here.<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="mso-fareast-language:EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="mso-fareast-language:EN-US">Thanks<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="mso-fareast-language:EN-US">Arnaud<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="mso-fareast-language:EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="mso-fareast-language:EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal" style="margin-left:35.4pt"><span lang="EN-US" style="color:black">I don’t think that increasing the scheduler’s parallelism would help, nor do I think you’d see a “stop-the-world”, but again, these hypotheses are just not actionable. There’s
nothing we can do to address them. When you find a problem, please report it and we’ll investigate what can be done.</span><span lang="EN-US">
<o:p></o:p></span></p>
<div>
<p class="MsoNormal" style="margin-left:35.4pt"><span lang="EN-US" style="color:black"><br>
<br>
</span><span lang="EN-US"><o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:35.4pt"><span lang="EN-US" style="color:black">— Ron</span><span lang="EN-US"><o:p></o:p></span></p>
<div>
<p class="MsoNormal" style="margin-left:35.4pt"><span lang="EN-US"><br>
<br>
<o:p></o:p></span></p>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<div>
<p class="MsoNormal" style="margin-left:35.4pt"><span lang="EN-US">On 6 Jan 2023, at 19:11, Arnaud Masson <</span><a href="mailto:arnaud.masson@fr.ibm.com"><span lang="EN-US">arnaud.masson@fr.ibm.com</span></a><span lang="EN-US">> wrote:<o:p></o:p></span></p>
</div>
<p class="MsoNormal" style="margin-left:35.4pt"><span lang="EN-US"><o:p> </o:p></span></p>
<div>
<div>
<p class="MsoNormal" style="margin-left:35.4pt"><span lang="EN-US">I don’t think having 100% CPU usage on a pod is enough to justify a “stop-the-world” effect on Loom scheduling for the other tasks.<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:35.4pt"><span lang="EN-US">Also 100% is the extreme case, but there can be 75% CPU usage, meaning only 1 carrier left for all other tasks in my example.<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:35.4pt"><span lang="EN-US"> <o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:35.4pt"><span lang="EN-US">Again not a blocker I guess, just have to increase the carrier count to mitigate, but it’s good old native thread sizing again where it should not be really needed.<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:35.4pt"><span lang="EN-US"> <o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:35.4pt"><span lang="EN-US">“Time-sharing would make those expensive tasks complete in a lot more than 10 seconds”:<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:35.4pt"><span lang="EN-US">I understand there would be switching overhead (so it’s slower), but I don’t understand why it would be<span class="apple-converted-space"> </span><i>much</i><span class="apple-converted-space"> </span>slower
if there are few of them like in my example.<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:35.4pt"><span lang="EN-US"> <o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:35.4pt"><span lang="EN-US">thanks</span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:35.4pt"><span lang="EN-US">Arnaud</span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:35.4pt"><span lang="EN-US"> </span><o:p></o:p></p>
</div>
</div>
</blockquote>
<p class="MsoNormal" style="margin-left:35.4pt"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:35.4pt"><o:p> </o:p></p>
</div>
</div>
</div>
<DIV>
Unless otherwise stated above:<BR>
<BR>
Compagnie IBM France<BR>
Siège Social : 17, avenue de l'Europe, 92275 Bois-Colombes Cedex<BR>
RCS Nanterre 552 118 465<BR>
Forme Sociale : S.A.S.<BR>
Capital Social : 664 069 390,60 €<BR>
SIRET : 552 118 465 03644 - Code NAF 6203Z<BR>
</DIV></body>
</html>