Simplify reclaim #1613
Closed
Simplify reclaim #1613
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
The reverts nearly all of the changes, with some adjustments to arc_memory_throttle() because some of the original code did not make sense and changes had been made to it since this patch was written. Signed-off-by: Richard Yao <[email protected]> Conflicts: module/zfs/arc.c
|
This should close issue #802. It implements what I sketched out there. |
|
I seem to have caught a regression: I am somewhat confused as to how arc_add_prune_callback is being listed in the backtrace. I believe that the problem is that the arc_shrinker is being invoked from the page fault handler. I am testing a revised patch that should address it. If all goes well, I will push it tomorrow. |
On Illumos, kswapd and arc_reclaim_thread share responsibility for memory reclaimation. arc_reclaim_thread will attempt to keep ahead of system memory needs and kswapd will signal it as needed. On Linux, a thread that needs memory when there is none available will immediately begin "direct reclaim", which means that it will try freeing memory itself. This poses a few problems. First, it is possible for hundreds of threads to enter direct reclaim. Unfortunately, only one can reclaim from ARC at a time. This means that one will reap while the others will be told to do other things. If we enter a state where ARC is the only source of memory available on the system, then we effectively have a fork bomb where all of the other reclaim threads will starve reclaimation from ARC of CPU time. Additionally, it is possible for ARC and Linux to have different ideas of when a system is low on memory. If Linux thinks it is out of memory and ARC disagrees, we will have a situation where arc_reclaim_thread spins. This patch attempts to address the first issue by signalling arc_reclaim_thread to enter reclaim and blocking until eitheri signalled by arc_reclaim_thread 1 second passes. Resuming after 1 second is necessary to resolve a race between arc_reclaim_thread doing its broadcast and sleeping. A previous patch had empirical success in resolving the second by moving primary responsibility for ARC memory reclaimation to the ARC shrinker callback. This patch moves all ARC memory reclaimation duties to arc_reclaim_thread, which should have a similar effect. Signed-off-by: Richard Yao <[email protected]>
|
I have pushed a revised commit that will return immediately when in an interrupt context to address the backtrace above. It will also return -1 instead of the amount reclaimed to ensure that shrink_slab() does not continuously retry the shrinker. This is consistent with openzfs/spl#268. |
|
This needs some more work. I am closing this until I have perfected it. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
I have been testing a revival of arc_reclaim where I make direct reclaim kick the arc_reclaim thread and block until either 1 second passes or it completes. It seems to work well and brings us more in line with other implementations.
I am opening this pull request for review. The manner in which the commits are split needs to be revisited before it is merged, but the end result seems sane to me.