Skip to content
New issue

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

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

Already on GitHub? # to your account

CASSANDRA-20333 Decaying histogram reservoir uses thread locals to store updates #4003

Open
wants to merge 15 commits into
base: trunk
Choose a base branch
from

Conversation

Mmuzaf
Copy link
Contributor

@Mmuzaf Mmuzaf commented Mar 23, 2025

Thanks for sending a pull request! Here are some tips if you're new here:

  • Ensure you have added or run the appropriate tests for your PR.
  • Be sure to keep the PR description updated to reflect all changes.
  • Write your PR title to summarize what this PR proposes.
  • If possible, provide a concise example to reproduce the issue for a faster review.
  • Read our contributor guidelines
  • If you're making a documentation change, see our guide to documentation contribution

Commit messages should follow the following format:

<One sentence description, usually Jira title or CHANGES.txt summary>

<Optional lengthier description (context on patch)>

patch by <Authors>; reviewed by <Reviewers> for CASSANDRA-#####

Co-authored-by: Name1 <email1>
Co-authored-by: Name2 <email2>

The Cassandra Jira

if (decaying.decayLandmark != decayingEstimatedBuckets.decayLandmark)
decayingEstimatedBuckets.flush(this, decaying);

decayingRef.get().update(index, now);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

do we need to do this get always twice?


public void update(int index, long now)
{
if (lastSampledClock != now)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

forwardDecayWeight actually uses seconds granularity, so we can reuse the value for much longer..

// try to use int[] instead of long[] to reduce memory usage, and move to the sum array when overflow
private final AtomicReference<DecayingArray> decayingRef;
private final long[] estimated;
private volatile boolean writing;
Copy link
Contributor

@netudima netudima Apr 7, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

potential false sharing with the array reference and decayingRef..

{
// This is only called by the thread that owns the thread local, so we don't need to worry about contention.
// Once the rescaling has occurred, we need to flush the values to the decayingBucket and report that the values are no longer in use.
writing = true;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

so, in the current implementation we have 2 volatile writes vs 2 addAndGet operations in the original one, without a contention they cost may be quite similar...

# for free to join this conversation on GitHub. Already have an account? # to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants