Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Remove needless locking and volatile access from QueryPhaseResultConsumer #119808

Closed

Conversation

original-brownbear
Copy link
Member

No need to have any synchronization here (it's obviously pointless since we are sorting the plain buffer outside of the block).
By forking the execution of reduce we establish a happens before edge already (and if we didn't fork we wouldn't have to worry about thread-safety anyway ...). => remove this, remove needless volatile from partial results flag and reduce volatile accesses. Also, while we're at it, null out the partial merge result early which might save non-trivial heap in some scenarios and run with a local reference.

Mainly motivated by the desire to execute reduce on transport threads when there's no aggs where synchronization ,even if not contended in this case, just wastes needless cycles and forces the reader to think about its latency implications.

…umer

No need to have any synchronization here (it's obviously pointless since we are sorting
the plain `buffer` outside of the block).
By forking the execution of `reduce` we establish a happens before edge already (and if we didn't fork
we wouldn't have to worry about a mutx anyway ...).
=> remove this, remove needless volatile from partial results flag and reduce volatile accesses.
Also, while we're at it, `null` out the partial merge result early which might save non-trivial
heap in some scenarios and run with a local reference.
@elasticsearchmachine elasticsearchmachine added the Team:Search Foundations Meta label for the Search Foundations team in Elasticsearch label Jan 8, 2025
@elasticsearchmachine
Copy link
Collaborator

Pinging @elastic/es-search-foundations (Team:Search Foundations)

@javanna
Copy link
Member

javanna commented Jan 16, 2025

I believe that this is entirely irrelevant after #119984 ? Can we close it?

@original-brownbear
Copy link
Member Author

Oh right sorry, actually the conclusion here was that the locking can't fully go away for now :) closing+thanks!

@original-brownbear original-brownbear deleted the less-locking-reduce branch January 16, 2025 11:02
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
>non-issue :Search Foundations/Search Catch all for Search Foundations Team:Search Foundations Meta label for the Search Foundations team in Elasticsearch
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants