Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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
Optimize freeMemorySpace() to not loop in vain #200
base: master
Are you sure you want to change the base?
Optimize freeMemorySpace() to not loop in vain #200
Changes from 10 commits
8cd8de0
03e1af3
2bc801d
ac3cf7c
33a2c2c
919a6df
df95793
b9d2033
4843b19
2340315
ec5917e
7820d21
6423c13
File filter
Filter by extension
Conversations
Jump to
There are no files selected for viewing
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
AFAICT, the implementation of this new method does not match its name/description. Even without collapsed forwarding going on, a locked() isAccepting() entry may be "being written" by another worker, right? Locked() is true for virtually every entry "in use" by a worker, and isAccepting() is roughly equivalent to STORE_PENDING, which is true for entries written by any worker IIRC.
This does not necessarily mean the old code using this method condition was wrong -- that condition evaluation could have been placed in the right context, making it correct. I did not check.
The method also appears to rely on a very dangerous assumption that it is only called for STORE_PENDING entries. I think that is a method description defect though -- isLocked() checks STORE_PENDING rather than assuming that the method was called for STORE_PENDING entries.
Please remove this used-twice method. If the above notes did not change your opinion on the condition applicability in the new code, then, in the new caller context, just add an extra assert() or Assure() for locked(). It will also help distinguish the failing condition if the new assertion is triggered.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Right (i.e. ,written to a shared store), but then copied to by another worker and then written to a local store. In this sense, any STORE_PENDING is probably a 'local writer' and it looks 'too broad' definition. I removed this method.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If possible, please reuse or merge with updateIdleNodes(). Refactor that method a little to be more reusable, as needed (e.g., giving it a second/newSize parameter?).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I was thinking to call one from another - but preconditions in these two methods a different - updateIdleNodes() is called only for idle nodes). I introduced a static helper method to avoid duplication.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nitpick: Please move these two lines up -- we do not need
delta
for this special noise-reduction(?) case.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ok.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Missing overflow protection. Please use one of the SquidMath.h "natural" functions to protect.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ok, but is there a possibility that the total number of pages (to say noting of idle pages) can exceed size_t maximum value?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Missing underflow protection. Please use one of the SquidMath.h "natural" functions to protect, adding one if necessary.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I am not sure that 'underflow' is applicable here. How can it happen? We checked that A >= B where both operands are size_t (an unsigned integer type) and then calculate A-B - we must get a size_t C >=0.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can we keep this assertion? It feels like it was correct or, at the very least, should not be removed in this PR.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Restored: this was first moved to isLocalWriter(), but then I forgot to undo after removing isLocalWriter().
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If this method survives, to simplify, reduce maintenance costs, and provide more info:
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I removed writeData() method.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is a new assertion (i.e. official code does not check this), right? It seems misplaced because it checks data_hdr-specific logic. Should not it go inside the mem_hdr::write() method instead? It is also rather weak and awkwardly phrased. I wonder whether this PR is the right place to add this assertion... In fact, should this PR add this method at all?? I suspect this method is no longer needed in this PR. If so, please remove instead of polishing.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This assertion was moved here from (removed) MemObject::write()). After our recent changes, I decided to remove writeData() at all and restore MemObject::write(). If we decide to refactor/eliminate the number off these write() methods scattered across several objects, let's do it separately.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If this method survives, please respect NDEBUG builds, even though Squid has a few other bugs like this already.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I removed writeData() method.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I suggest using allowedToFreeWithReplPolicy() "OK to call twice with the same value" convenience/safety feature and avoiding questions about the
else
case:Alternatively, we should document what is going on in that (somewhat expected or should-be-common)
else
case:I prefer the simplicity and clarity of the first variant, despite the extra function calls it causes. If those extra function calls are a concern, we should refactor allowedToFreeWithReplPolicy() declaration/implementation a little, to allow the compiler to inline the no-changes check into callers.
I applied the same logic in another allowedToFreeWithReplPolicy(true) change request, without an explanation.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I applied the first suggestion.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think we should drop this new condition and the corresponding new method: If we need to assert() that ENTRY_SPECIAL entries are not counted/tracked, we should do that explicitly somewhere (not here where we explicitly check for ENTRY_SPECIAL and mem_obj) rather than implicitly (and rather unexpectedly and dangerously!) in all hasReplPolicy() callers.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ok, I dropped the method but I think we need a condition (at least for data_hdr.allowedToFreeWithReplPolicy() call): we should skip this call when entry is not in memory policy. On the other hand, mem_policy->Remove() can be called twice - it has a such a check inside.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Undo as no longer necessary?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Undone.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Remove as unused?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Removed.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Please use Less() for this comparison to avoid casting and clarify what is going on here: