Cache topology aware scheduling

[Danny Thomas]

I've switched to foreign functions for the native calls, using the current
CPU for external submissions, and a queuing threshold to decide when to
select the least loaded pool. Significantly improved CPU utilization versus
the default scheduler with a slight throughput bump:

https://github.com/DanielThomas/virtual-threads-cluster-aware/commit/c0e7b6141a84eb77e6848fa84014e7a98ddfc75b

I'll improve the benchmark to be lumpier with more submission pressure to
make work stealing more of a factor, and then look at balancing with
pollSubmission.

On Sat, Sep 7, 2024 at 11:23 PM Danny Thomas <dannyt at netflix.com> wrote:

> Yup, that’s it exactly. I’m planning on trying cluster affinity based on
> the current CPU for submitting/unparking platform thread, and was going to
> explore balancing while I was at it.
>
> On Sat, 7 Sep 2024 at 11:15 PM, Alan Bateman <alan.bateman at oracle.com>
> wrote:
>
>> On 06/09/2024 08:10, Danny Thomas wrote:
>>
>> Thanks Franz, Alan,
>>
>> I spun up a quick experiment with a custom scheduler here:
>>
>> https://github.com/DanielThomas/virtual-threads-cluster-aware
>> <https://urldefense.com/v3/__https://github.com/DanielThomas/virtual-threads-cluster-aware__;!!ACWV5N9M2RV99hQ!LpIm0wPe4UjF5tJvF0CQKTE98rTBgsqe-WIHDLDCt3HheQHfb-ldWdCf7vfWNxI8nEmUjf3AyP91_aq0XA$>
>>
>>
>> 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.
>>
>>
>> -Alan
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/loom-dev/attachments/20240910/2a9c2f64/attachment.htm>