<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class="">
<br class="">
<div><br class="">
<blockquote type="cite" class="">
<div class="">On 9 Jan 2023, at 19:02, Arnaud Masson <<a href="mailto:arnaud.masson@fr.ibm.com" class="">arnaud.masson@fr.ibm.com</a>> wrote:</div>
<br class="Apple-interchange-newline">
<div class="">
<div class="WordSection1" style="page: WordSection1; caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: 400; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none;">
<div style="margin: 0cm; font-size: 11pt; font-family: Calibri, sans-serif;" class="">
<span lang="EN-US" class="">My concern right now is not constant high rate of slowCPURequets or having Loom threads handle arbitrary high CPU load for long time.<o:p class=""></o:p></span></div>
<div style="margin: 0cm; font-size: 11pt; font-family: Calibri, sans-serif;" class="">
<span lang="EN-US" class="">It’s just that Loom (default Executor) makes some real scenarios worse compared to classic Executor, like the modest burst of slowCPURequests causing brutal pause on fastIORequests in the code example.<o:p class=""></o:p></span></div>
<div style="margin: 0cm; font-size: 11pt; font-family: Calibri, sans-serif;" class="">
<span lang="EN-US" class=""><o:p class=""> </o:p></span></div>
</div>
</div>
</blockquote>
<div><br class="">
</div>
<div>I don’t think that’s true. The only scenarios where we’ve seen that situation is “worse” (under the assumption that you want to increase latency for long tasks and decrease it for short tasks) is are those where it is trivial to pick a different scheduler
once the programmer decides they have a preference for one scheduling policy over another. We have not seen situations where virtual threads are the obvious choice and yet you see a problem. We would be very interested in finding them so we could study them.
But please assume that any *hypothetical* scenario that could be considered has already been.</div>
<div><br class="">
</div>
<div>
<div>I was hoping to clarify why after spending years considering hypotheses we’re at a point we need more actual data, not the same hypotheses we’ve already considered. Every single hypothetical case you bring up has already been considered, and we concluded
that the only thing we can do is wait until someone actually encounters it in the field. </div>
<div class=""><br class="">
</div>
</div>
<br class="">
<blockquote type="cite" class="">
<div class="">
<div class="WordSection1" style="page: WordSection1; caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: 400; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none;">
<div style="margin: 0cm; font-size: 11pt; font-family: Calibri, sans-serif;" class="">
<span lang="EN-US" class="">(Again, there are workarounds, but it makes Loom transition more complex/sensitive for _some_ webapps.)</span></div>
</div>
</div>
</blockquote>
<div><br class="">
</div>
<div>A workaround implies someone has encountered a problem. We first need to establish that some webapps find this more complex, and we can’t even do that until they report a problem. </div>
<br class="">
<blockquote type="cite" class="">
<div class="">
<div class="WordSection1" style="page: WordSection1; caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: 400; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none;">
<div style="margin: 0cm; font-size: 11pt; font-family: Calibri, sans-serif;" class="">
<span lang="EN-US" class=""><o:p class=""></o:p></span></div>
<div style="margin: 0cm; font-size: 11pt; font-family: Calibri, sans-serif;" class="">
<span lang="EN-US" class=""><o:p class=""> </o:p></span></div>
<div style="margin: 0cm; font-size: 11pt; font-family: Calibri, sans-serif;" class="">
<span lang="EN-US" class="">About the operational band:<o:p class=""></o:p></span></div>
<div style="margin: 0cm; font-size: 11pt; font-family: Calibri, sans-serif;" class="">
<span lang="EN-US" class="">Let’s say C is the number is of available CPUs (or Pod CPU limit)<o:p class=""></o:p></span></div>
<div style="margin: 0cm; font-size: 11pt; font-family: Calibri, sans-serif;" class="">
<span lang="EN-US" class="">and M the max number of active native threads beyond which your pod becomes useless.<o:p class=""></o:p></span></div>
<div style="margin: 0cm; font-size: 11pt; font-family: Calibri, sans-serif;" class="">
<span lang="EN-US" class="">You assume any concurrent CPU activity between C and M is irrelevant, but it doesn’t make sense for me: why would it be better to be stuck suddenly with long pauses at C rather than scaling gracefully until M?</span></div>
</div>
</div>
</blockquote>
<div><br class="">
</div>
Time-sharing doesn’t “scale gracefully”. It decreases the latency for some tasks at the cost of increasing it for others (and sometimes increasing the average), while having no impact on scalability (scheduling cannot affect scalability).</div>
<div><br class="">
<blockquote type="cite" class="">
<div class="WordSection1" style="page: WordSection1; caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: 400; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none;">
<div style="margin: 0cm; font-size: 11pt; font-family: Calibri, sans-serif;" class="">
<span lang="EN-US" class=""><o:p class=""></o:p></span></div>
<div style="margin: 0cm; font-size: 11pt; font-family: Calibri, sans-serif;" class="">
<span lang="EN-US" class=""><o:p class=""> </o:p></span></div>
<div style="margin: 0cm; font-size: 11pt; font-family: Calibri, sans-serif;" class="">
<span lang="EN-US" class="">Interestingly, the scenario you consider (</span><span lang="EN-US" class="">postponing a batch job to run at a much later time) is less relevant in my opinion in modern cloud environment where you want your pod to migrate smoothly
but quickly (save state/stop/restart/reload state in a few minutes max) during cluster scaling for example.<o:p class=""></o:p></span></div>
<div style="margin: 0cm; font-size: 11pt; font-family: Calibri, sans-serif;" class="">
<br class="">
</div>
</div>
</blockquote>
<div><br class="">
</div>
<div>Quite possibly, but given that a big company has actually presented us with a real problem they encountered while no one has reported a problem of the kind we’re discussing, our only course of action is to prioritise the problem that we know exists. There
really is absolutely nothing we can do about problems that have not been reported, no many how many times we consider hypotheticals.</div>
<div><br class="">
</div>
<div>If you can’t accept it as the only reasonable course of action, please accept it as an arbitrary axiom: until someone reports a problem they’ve actually encountered in some reasonable program, we cannot consider requests for changes. If the problem is
likely to occur, then someone will surely report it soon enough and we could start studying it.</div>
<div><br class="">
</div>
<div>There’s no point in arguing over this axiom, and the only insight that can help us move forward is real data from the field.</div>
<div><br class="">
</div>
<div>— Ron</div>
</div>
</body>
</html>