Cache topology aware scheduling

[Alan Bateman]

On 04/10/2024 07:13, Danny Thomas wrote:
> 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:
>
> https://github.com/DanielThomas/virtual-threads-cluster-aware/blob/main/src/main/java/com/netflix/sandbox/ClusteredExecutors.java 
> <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$>
>
> 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.
>
Thanks for the update, it's nice to get periodic "status reports" on 
experiments in this area.

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.

-Alan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/loom-dev/attachments/20241004/2ed58cc1/attachment.htm>