<!DOCTYPE html><html><head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
  </head>
  <body>
    On 04/10/2024 07:13, Danny Thomas wrote:<br>
    <blockquote type="cite" cite="mid:CAABjz13TtAbBzDGeMU3P9VDp3s2pDD3GwODXczVpxqtuGi2CAg@mail.gmail.com">
      
      <div dir="ltr">After quite a bit of experimentation, I can at
        least say that last level cache aware task placement on 4th
        Generation EPYC (Genoa) is a real boon. I generalised my
        original approach, because it doesn't involve customizing the
        nodes-per-socket setting (which we can't do on AWS anyway, NPS =
        1), introduce the risks/complexity of processor isolation and
        per-thread affinity, or make the scheduler's life too difficult:<br>
        <br>
        <a href="https://urldefense.com/v3/__https://github.com/DanielThomas/virtual-threads-cluster-aware/blob/main/src/main/java/com/netflix/sandbox/ClusteredExecutors.java__;!!ACWV5N9M2RV99hQ!NSA8NGBYdS4YOkzpmpUb-x03qPs0pd5lMgqqL7SjRr1z53q7xWTCHwpaUxPCDX-TTx3NcuqqRnQtvCsTfw$" moz-do-not-send="true">https://github.com/DanielThomas/virtual-threads-cluster-aware/blob/main/src/main/java/com/netflix/sandbox/ClusteredExecutors.java</a><br>
        <br>
        With virtual-to-virtual-thread submissions and particularly
        structured concurrency providing a heuristic for locality, I'm
        convinced there's a significant opportunity here. I've still got
        some more real world experiments to run, but will get a TechBlog
        post up when I have something to share.</div>
      <br>
    </blockquote>
    Thanks for the update, it's nice to get periodic "status reports" on
    experiments in this area.<br>
    <br>
    One issue that I assume will be problematic without API support is
    when a virtual thread T unparks another virtual thread. The execute
    method will be called in the context of currentThread=T, not T's
    carrier. Until recently it was called in the context of T's carrier
    (for reasons that are too complicated to get into here) which has a
    bunch of implications that have now been smoothed out. For your
    experiments I suspect this means it will fallback to round robin or
    choose a random pool. It's a topic that needs a more thought as some
    custom schedulers will need the carrier's identity or maintain a
    mapping of virtual thread to "place", "place" in this case is the
    cluster. <br>
    <br>
    -Alan<br>
  </body>
</html>