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 9 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.
This method implementation looks simple, but its hidden preconditions and/or implications are actually rather complex! This method cannot be correctly used/interpreted except in some very specific code places -- move its call a few lines up or down, and it will fail to work.
The method also exposes a potential terminology problem: Either we should not be checking ENTRY_SPECIAL (because ENTRY_SPECIAL is never idle) OR we are not really counting idle pages (i.e. we are counting "purge-able" pages).
For now, I suggest just inlining this method calls (and adjusting a bit to remove checks that are not necessary in each particular context). If, at the end of this PR, we still see reusable code that is more-or-less safe to call from various places, we will find a way to encapsulate it again.
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 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 this code survives, I suggest relaxing it -- doing nothing when idleness does not change. It may even simplify some 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.
Removed this assertion.
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.
Why do we need to call this explicitly here? In other words, why cannot dataHdr.write() adjust the idle page counter as needed? Do we not trust its isIdle state??
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 this call.
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.
Feels wrong that we do not care about ENTRY_SPECIAL here. If (current or future) code reaches this place with an unlocked ENTRY_SPECIAL, we will count "idle" pages we should not count... I hope we can refactor this PR to avoid this problem, but, for now, let's just add an XXX:
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 this constructor argument. After modifying the condition used for making pages idle (i.e., it should be in a policy) I added an assertion into the MemObject constructor.
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.