[
https://issues.apache.org/jira/browse/CASSANDRA-20176?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17915804#comment-17915804
]
Benedict Elliott Smith commented on CASSANDRA-20176:
----------------------------------------------------
[~jmckenzie]: virtual threads have an executor substrate (by default
ForkJoinPool - in fact, using something else is sort of hard today), so it's
probably an orthogonal topic - and using them effectively is somewhat harder.
I'm actually somewhat happy to see this initial investigation shows SEP still
offers value, even if it complicates how we proceed with our executor story -
if only because it's nice to see your work isn't defunct. Thanks for running
this investigation.
I'm not sure we need to do lots more validating SEP at this point to be honest,
this corroborates at least that it isn't sensible to prioritise replacing it.
So, if you feel a burning desire to improve its allocation rate feel free. But:
1) it looks like the SEP run used less memory anyway?
2) I should note I don't (and won't for perhaps a year) have any free time to
really facilitate, as all of my spare time is spent on Accord, so I can't
promise any help landing a patch you might produce
> Reduce memory allocation in SEP Worker spin wait logic
> ------------------------------------------------------
>
> Key: CASSANDRA-20176
> URL: https://issues.apache.org/jira/browse/CASSANDRA-20176
> Project: Apache Cassandra
> Issue Type: Improvement
> Components: Local/Other
> Reporter: Dmitry Konstantinov
> Assignee: Dmitry Konstantinov
> Priority: Normal
> Attachments: image-2025-01-01-13-14-02-562.png,
> image-2025-01-01-13-15-16-767.png, ttop_disabled_sep.txt, ttop_enabled_sep.txt
>
>
> There is a visible memory allocation within spin waiting logic in SEP
> Executor: org.apache.cassandra.concurrent.SEPWorker#doWaitSpin for some
> workloads. For example it is observed for a writing test described in
> CASSANDRA-20165 where ~8.5% of total allocations are from this logic:
> !image-2025-01-01-13-14-02-562.png|width=570!
> !image-2025-01-01-13-15-16-767.png|width=570!
> The idea of this parking is to avoid unpark signalling costs. The logic
> selects a random time period to park a thread by LockSupport.parkNanos and
> put the thread into a ConcurrentSkipListMap using wake up time as a key, so
> the map is used as a concurrent priority queue. Once the parking is finished
> - the thread removes itself from the map. When we neede to schedule a task -
> we take a spinning thread with the smallest wake up time from the map.
> We can try to implement another algorithm for this logic without memory
> allocation overheads, for example based on a Timing Wheel data structure.
> Note: it also makes sense to check granularity of actual parking time
> (https://hazelcast.com/blog/locksupport-parknanos-under-the-hood-and-the-curious-case-of-parking/)
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
