Performance Questions and Poller Implementation in Project Loom

[Alan Bateman]

On 01/11/2023 20:13, Ilya Starchenko wrote:
> :
>
>
> Firstly, with the ReadPoller and WritePoller now being based on the 
> number of hardware threads, could you please clarify the MasterPoller 
> is used to make the polling mechanism non-blocking as well?(there's no 
> events, so we park)
>
>
> Secondly, from what I can gather, the Poller itself is used only to 
> polling events(obviously) and park/depark vthread. However, the actual 
> reading from buffers and writing to the OS buffer is performed by the 
> virtual threads themselves, which can be executed by any platform 
> thread. There is no performance lack in this case, because we kinda 
> losing data locality(due to virtual threads being carried by any 
> platform thread without affinity)? Have you considered to make all 
> network operations to the platform thread and reserving virtual 
> threads solely for user code execution when data is ready?
>
>
> I apologize if I've misunderstood any aspects of the architecture, and 
> I'm genuinely trying to gain a better understanding of how it all works.
>
>
In this mode, the read and write pollers do not block wait for events. 
If there are no events then a poller will register with the master 
poller and park. So think of the master poller as the lender of last resort.

I think you may have missed that unparking queues the virtual thread to 
continue on the same carrier that the poller is mounted on. The poller 
yields so queues itself to continue on the same carrier. In a busy 
system this works quite well, less so when less busy as stealing may 
mean the virtual thread and poller move to other carriers.

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