<!DOCTYPE html><html><head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body>
On 06/09/2024 08:10, Danny Thomas wrote:<br>
<blockquote type="cite" cite="mid:CAABjz12=s9yVkRzo09x77U4w2x1ank2LhqEqKNaWnY3NXVcOog@mail.gmail.com">
<div dir="ltr">Thanks Franz, Alan,<br>
<br>
I spun up a quick experiment with a custom scheduler here:<br>
<br>
<a href="https://urldefense.com/v3/__https://github.com/DanielThomas/virtual-threads-cluster-aware__;!!ACWV5N9M2RV99hQ!LpIm0wPe4UjF5tJvF0CQKTE98rTBgsqe-WIHDLDCt3HheQHfb-ldWdCf7vfWNxI8nEmUjf3AyP91_aq0XA$" moz-do-not-send="true">https://github.com/DanielThomas/virtual-threads-cluster-aware</a><br>
</div>
</blockquote>
<br>
Would I be correct to say that this experiment is a FJP (in
async/fifo mode) for each "cluster" with the worker threads bound to
the processors in that cluster. A "front-end" scheduler forwards
tasks to one of the FJP instances. If a platform thread starts or
unparks a virtual thread then the target's task will be submitted to
a random FJP instance. If a virtual thread starts or unparks another
virtual thread then it will be submitted to the "current" FJP.
Assuming I have this right thing I would expect it works well for
workloads where there are platform threads in the picture as that
will have the effect of balancing the load across the FJP instances.
In other cases then I assume it could be a bit unbalanced, at least
not without something that nudges virtual threads to other clusters.<br>
<br>
-Alan<br>
</body>
</html>