-
Notifications
You must be signed in to change notification settings - Fork 3.3k
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
HBASE-27867 Close the L1 victim handler race #5239
Conversation
💔 -1 overall
This message was automatically generated. |
🎊 +1 overall
This message was automatically generated. |
💔 -1 overall
This message was automatically generated. |
I checked out the branch I pushed and ran
The test issue is not a unit test failure and does not appear to be related to this change. Looks like we may need to do a zombie cleanup.
|
hbase-server/src/main/java/org/apache/hadoop/hbase/io/hfile/LruBlockCache.java
Outdated
Show resolved
Hide resolved
hbase-server/src/main/java/org/apache/hadoop/hbase/io/hfile/LruBlockCache.java
Show resolved
Hide resolved
hbase-server/src/main/java/org/apache/hadoop/hbase/io/hfile/LruBlockCache.java
Outdated
Show resolved
Hide resolved
hbase-server/src/main/java/org/apache/hadoop/hbase/io/hfile/LruBlockCache.java
Show resolved
Hide resolved
When we evict a block from L1 and move it to L2 there is a brief window of time where we have removed the block from the L1 map and yet the victim handler has not completed execution. Some read-your-write use cases can be significantly impacted even though the window is small. Victim handling can be made atomic with respect to the unmapping operation. The upside is there will be no L1+L2 misses during the transition. The downside is if the victim handler takes a long time to execute – currently they are all very fast, so only a theoretical risk – then other removals or insertions in L1 can block until it completes.
Rebased. Addressed review feedback. |
💔 -1 overall
This message was automatically generated. |
🎊 +1 overall
This message was automatically generated. |
💔 -1 overall
This message was automatically generated. |
@Apache9 please let me know if you have any more concerns or nits. I plan to merge this tomorrow. |
When we evict a block from L1 and move it to L2 there is a brief window of time where we have removed the block from the L1 map and yet the victim handler has not completed execution. Some read-your-write use cases can be significantly impacted even though the window is small. Victim handling can be made atomic with respect to the unmapping operation. The upside is there will be no L1+L2 misses during the transition. The downside is if the victim handler takes a long time to execute – currently they are all very fast, so only a theoretical risk – then other removals or insertions in L1 can block until it completes. Signed-off-by: Duo Zhang <zhangduo@apache.org> Signed-off-by: Viraj Jasani <vjasani@apache.org>
When we evict a block from L1 and move it to L2 there is a brief window of time where we have removed the block from the L1 map and yet the victim handler has not completed execution. Some read-your-write use cases can be significantly impacted even though the window is small. Victim handling can be made atomic with respect to the unmapping operation. The upside is there will be no L1+L2 misses during the transition. The downside is if the victim handler takes a long time to execute – currently they are all very fast, so only a theoretical risk – then other removals or insertions in L1 can block until it completes. Signed-off-by: Duo Zhang <zhangduo@apache.org> Signed-off-by: Viraj Jasani <vjasani@apache.org>
When we evict a block from L1 and move it to L2 there is a brief window of time where we have removed the block from the L1 map and yet the victim handler has not completed execution. Some read-your-write use cases can be significantly impacted even though the window is small. Victim handling can be made atomic with respect to the unmapping operation. The upside is there will be no L1+L2 misses during the transition. The downside is if the victim handler takes a long time to execute – currently they are all very fast, so only a theoretical risk – then other removals or insertions in L1 can block until it completes.