<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.EmailStyle18
{mso-style-type:personal-reply;
font-family:"Calibri",sans-serif;
color:windowtext;}
.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">Side note : it seems “more” preemptive time sharing was added for goroutines in Go 1.14 to avoid the kind of scheduling starvation we discussed:<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"><a href="https://medium.com/a-journey-with-go/go-asynchronous-preemption-b5194227371c">https://medium.com/a-journey-with-go/go-asynchronous-preemption-b5194227371c</a><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>
<div>
<p class="MsoNormal" style="margin-left:35.4pt;mso-line-height-alt:.75pt"><span lang="EN-US" style="font-size:1.0pt;color:white">I don’t know how to ev<o:p></o:p></span></p>
</div>
<p class="MsoNormal" style="margin-left:35.4pt"><span lang="EN-US" style="color:black">I don’t know how to evaluate and compare solutions before knowing what the problem they supposedly solve is, so I have no way of knowing which if any of time-sharing for
virtual threads or adding scheduler workers is a better solution to a problem that hasn’t been reported.</span><span lang="EN-US">
<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">If servers employing virtual threads tend to reach conditions where time-sharing could help, then when the problem is reported we would be more than happy to fix it with that solution. What I’m trying to convey
is not that I think your hypothesis must be wrong, but that it is not necessarily correct, either, and so we are simply unable to fix hypothetical bugs. It really doesn’t matter how strongly anyone feels that some problem *could* arise. We cannot fix bugs
before they are reported, so that we can assess their severity, prioritise them, and consider solutions. If you do find a problem with virtual threads, please report it to this mailing list. <o:p></o:p></p>
<div>
<p class="MsoNormal" style="margin-left:35.4pt"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:35.4pt">— Ron<o:p></o:p></p>
<div>
<p class="MsoNormal" style="margin-left:35.4pt"><o:p> </o:p></p>
</div>
<div>
<div>
<p class="MsoNormal" style="margin-left:35.4pt"><o:p> </o:p></p>
<div>
<p class="MsoNormal" style="margin-left:35.4pt"><br>
<br>
<o:p></o:p></p>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<div>
<p class="MsoNormal" style="margin-left:35.4pt">On 8 Jan 2023, at 23:19, Robert Engels <<a href="mailto:rengels@ix.netcom.com">rengels@ix.netcom.com</a>> wrote:<o:p></o:p></p>
</div>
<p class="MsoNormal" style="margin-left:35.4pt"><o:p> </o:p></p>
<div>
<div>
<p class="MsoNormal" style="margin-left:35.4pt">We’ll have to agree to disagree. I think servers routinely hit 100% cpu and rely on the scheduler to deprioritize tasks to be fair - maybe not “forever” but for extended periods.
<br>
<br>
This is not dissimilar to the various background tools for cosmos searching that use the available cycles - as long as nothing else needs them.
<br>
<br>
I am guessing a lot of long running simulations work similarly. <br>
<br>
As I’ve said though I don’t think it’s a huge deal - move things that have to run to their own native thread pool. Maybe that’s a better and simpler solution than trying to add time slicing to vthreads anyway.
<br>
<br>
<br>
<o:p></o:p></p>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<p class="MsoNormal" style="margin-left:35.4pt">On Jan 8, 2023, at 5:05 PM, Ron Pressler <<a href="mailto:ron.pressler@oracle.com">ron.pressler@oracle.com</a>> wrote:<br>
<br>
<br>
<br>
<br>
<o:p></o:p></p>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<p class="MsoNormal" style="mso-margin-top-alt:0cm;margin-right:0cm;margin-bottom:12.0pt;margin-left:35.4pt">
On 8 Jan 2023, at 18:58, robert engels <<a href="mailto:rengels@ix.netcom.com">rengels@ix.netcom.com</a>> wrote:<br>
<br>
But even if not using spin locks - with fair scheduling you expect shorter runtime tasks to be completed before long-running cpu bound tasks. The linux scheduler will lower the priority of threads that hog the cpu too much to facilitate this even further (or
use a scheduler type of ‘batch/idle’ - i.e. only run when nothing else needs to run).<o:p></o:p></p>
</blockquote>
<p class="MsoNormal" style="margin-left:35.4pt"><br>
If you use spin locks and have significantly more threads than cores, you may well experience an orders of magnitud slow-down. I.e., you don’t use spin locks and rely on time-sharing to make them work well — there won’t be a deadlock, but you won’t get an acceptable
behaviour, either.<br>
<br>
<br>
<br>
<o:p></o:p></p>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<p class="MsoNormal" style="margin-left:35.4pt">So if very short tasks get stuck behind long-running cpu bound tasks this is unexpected behavior - it is not necessarily incorrect. If you spawned more carrier threads (i.e. when the scheduler feels the tasks
are not making “progress”) you give more of a chance for the OS scheduler to give cpu time to the short lived tasks. I think that is what the OP was trying to say.<o:p></o:p></p>
</blockquote>
<p class="MsoNormal" style="margin-left:35.4pt"><br>
This may seem obvious at first, but the easiest way to explain why it’s hard to find an actual problem caused by this (and why you don’t actually rely on the “expected behaviour”) is to remember that the OS will do this (pretty-much) only when your CPU is at
100%. But at that point, there’s very little the OS can do to make your server behave well. When you’re at 100% CPU for any significant duration, since requests keep coming, they’re piling up and your server is now unstable. In other words, time sharing only
kicks in when it can’t do much good.<br>
<br>
In non-realtime kernels, time-sharing is mostly used to run a small number of background tasks or to keep the machine responsive to an operator in cases of emergency. Clever scheduling is not enough to compensate for lack of resources. Time sharing can also
be useful for to smooth over the latency of CPU-bound batch-processing tasks, but since it only makes sense to run only a few of them in parallel, virtual threads can’t give you any benefit there anyway.<br>
<br>
However, as I’ve said multiple times already, we don’t rule out the possibility of a workload where time sharing could solve an actual problem. So if you encounter a problem, please report it.<br>
<br>
— Ron<o:p></o:p></p>
</blockquote>
</div>
</div>
</blockquote>
</div>
<p class="MsoNormal" style="margin-left:35.4pt"><o:p> </o:p></p>
</div>
</div>
</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>