On Thu, 26 Mar 2026 17:42:05 GMT, Alan Bateman <[email protected]> wrote:
>> Francesco Nigro has updated the pull request incrementally with one >> additional commit since the last revision: >> >> Disable edge-triggered epoll for POLLER_PER_CARRIER mode >> >> Per-carrier sub-pollers have carrier affinity, which creates a >> scheduling conflict with edge-triggered registrations: the sub-poller >> competes with user VTs for the same carrier. By the time the sub-poller >> runs, user VTs have often already consumed data via tryRead(), causing >> the sub-poller to find a POLLED sentinel and waste a full park/unpark >> cycle on the master (each costing an epoll_ctl). Under load this >> causes a 2x throughput regression. >> >> VTHREAD_POLLERS mode is unaffected because its sub-pollers have no >> carrier affinity and can run on any available carrier, processing >> events before user VTs consume the data. > > This looks like a 1% improvement in ops/sec. I think we'll need to get a more > real-world benchmark. Do you have something other than the micro. > > Do you agree with the proposal to put this in its own branch so that we can > iterate on it? > @AlanBateman let me know how they looks like 🙏 I will look at it more closely next week. I have a strong preference that this goes into its own branch as a prototype as it will go through many iterations. Edge triggered mode is really fragile and high dependent on usage patterns. I think the only reason is works here is that the usages that read will only attempt to poll/arm when there are no bytes available. There are many scenarios that will need to worked through to build up confident and I think will need a knob to opt-in or opt-out. ------------- PR Comment: https://git.openjdk.org/loom/pull/223#issuecomment-4143630428
