Cache topology aware scheduling

[Danny Thomas]

Thanks Franz, Alan,

I spun up a quick experiment with a custom scheduler here:

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

Have a good weekend,
Danny

On Fri, Sep 6, 2024 at 2:16 AM Francesco Nigro <nigro.fra at gmail.com> wrote:

> Hi @Danny Thomas <dannyt at netflix.com>
>
> We're working (nudge nudge Andrew Haley) on a custom scheduler API - as
> mentioned by Alan, which enables (expert) users/framework devs to implement
> something like this - and more :)
>
> Cheers,
> Franz
>
>
>
> Il giorno lun 2 set 2024 alle ore 10:41 Alan Bateman <
> alan.bateman at oracle.com> ha scritto:
>
>> On 02/09/2024 07:23, Danny Thomas wrote:
>> > Hi folks,
>> >
>> > I was giving some thought to our adoption of Xen 4 coinciding with
>> > virtual threads being available, and it occurred to me with an
>> > increasing number of architectures clustering L3 and L2 caches between
>> > groups of cores on a die, that virtual threads scheduling in user
>> > space could make them particularly well suited to these architectures,
>> > if the scheduler were topology aware.
>> >
>> > Have you given any thought to worker CPU affinity and/or locality to
>> > an existing worker when a virtual thread is started by another? Would
>> > you consider this something to be proved out by custom schedulers, or
>> > is this enough of a trend to justify future investment in the default
>> > scheduler?
>>
>> To date, we've put CPU and node affinity into the "custom scheduler"
>> topic, which is still TBD on whether to expose. If you have data from
>> any experiments with the current EA builds then it would be useful to
>> see. The current EA builds allow the the default FJP based scheduler to
>> be replaced for experimentation purposes.
>>
>> In a system with a mix of schedulers then starting a virtual thread will
>> "inherit" the scheduler when not configured. That seems a sensible
>> default.
>>
>> -Alan
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/loom-dev/attachments/20240906/39104b54/attachment.htm>