: Re: Project Loom VirtualThreads hang

[Ron Pressler]

On 6 Jan 2023, at 11:49, Arnaud Masson <arnaud.masson at fr.ibm.com<mailto:arnaud.masson at fr.ibm.com>> wrote:

As I said, it would not be as bad as the NodeJS example but still a similar problem: a native thread pinned by CPU-bound request.

It is a phenomenon. Whether or not it’s a problem is still to be determined.


If I have a Kub pod with CPU limit 2, I send 4 CPU-bound http requests concurrently, I really expect them to run concurrently, not 2 then 2 – it’s rather real world scenario.

And in most situations they will run in parallel, and in those they won’t, chances are that you won’t notice or it doesn’t matter as your server is already sputtering.

Sure, if you have 100% CPU usage all the time there is a problem, but that doesn’t mean incoming requests should be fully stuck as soon as 100% CPU usage is hit on a pod.
(Note that 100% usage on Pod doesn’t mean 100% on the underlying worker node VM.)

The problem here is not raw performance but scheduling fairness.
In my opinion, for CPU-bound requests on vthreads, that would be even better to have slightly worse perf overall but maintain correct fairness.
Otherwise, we will have to be concerned each time about running enough carrier/native threads to support possible worst-case concurrent CPU-bound requests – compared with the awesome simplification Loom gives regarding blocked IO handling.

From a different perspective: I think Loom cheap stack/thread parking could be useful also for CPU-bound tasks. It could allow more concurrent CPU-bound tasks to make progress without improving perf overall.


What you’re showing is not a problem. It’s a scenario that you hypothesise could be a problem, and then you further hypothesise that a certain mechanism would fix the hypothetical problem. But we can’t fix something until we see an actual problem and know what it is that requires fixing.

In particular, I don’t know why you have to be preemptively concerned about a problem you have not seen, and that platform threads aren’t known to address either. In fact, virtual threads already give you better fairness than both platform thread pools and async code. So are you concerned that virtual threads will improve things but not to the extent you wish there was something that could?

— Ron

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/loom-dev/attachments/20230106/68c1e90f/attachment-0001.htm>