[External] : Re: Experience using virtual threads in EA 23-loom+4-102

[Attila Kelemen]

I think you somewhat misunderstood Ron's comment on "same". Same means that
they are progressing the same task. For example, you have a large composite
task which  is made up of 100 small chunks, and then you start these 100
chunks of work in parallel. If you are fair, then what you will see is that
0%, 0% ... and suddenly 100% when all of them are completed (assuming total
fairness). While in case of non-fair, you will see progress that few chunks
done, yet a few more done, etc.

Robert Engels <robaho at icloud.com> ezt írta (időpont: 2024. júl. 3., Sze,
18:44):

> I don't think that is correct - but I could be wrong.
>
> With platform threads the min and max latency in a completely cpu bound
> scenario should be very close the the average with a completely fair
> scheduler (when all tasks/threads are submitted at the same time).
>
> Without timesharing, the average will be the same, but the min and max
> latencies will be far off the average - as the tasks submitted first
> complete very quickly, and the tasks submitted at the end take a very long
> time because they need to have all of the tasks before them complete.
>
> In regards to the the “enough cpus” comment, I only meant that if there
> are enough cpus and a “somewhat” balanced workload, it is unlikely that all
> of the cpu bounds tasks could consume all of the carrier threads given a
> random distribution. If you have more active tasks than cpus and the
> majority of the tasks are cpu bound, the IO tasks are going to suffer in a
> non-timesliced scenario - they will be stalled waiting for a carrier thread
> - even though the amount of cpu they need will be very small.
>
> This has a lot of info on the subject
> https://docs.kernel.org/scheduler/sched-design-CFS.html including:
>
> On real hardware, we can run only a single task at once, so we have to
> introduce the concept of “virtual runtime.” The virtual runtime of a task
> specifies when its next timeslice would start execution on the ideal
> multi-tasking CPU described above. In practice, the virtual runtime of a
> task is its actual runtime normalized to the total number of running tasks.
>
> I recommend this
> https://opensource.com/article/19/2/fair-scheduling-linux for an in-depth
> discussion on how the dynamic timeslices are computed.
>
> The linux scheduler relies on timeslicing in order to have a “fair”
> system. I think most Java “server” type applications strive for fairness as
> well - i.e. long tail latencies in anything are VERY bad (thus the constant
> fight against long GC pauses - better to amortize those for consistency).
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/loom-dev/attachments/20240703/ed4beb1f/attachment.htm>