Shadow entries in the page cache used to be accounted behind the radix
tree implementation's back in the upper bits of node->count, and the
radix tree code extending a single-entry tree with a shadow entry in
root->rnode would corrupt that counter. As a result, we could not put
shadow entries at index 0 if the tree didn't have any other entries,
and that means no refault detection for any single-page file.
Now that the shadow entries are tracked natively in the radix tree's
exceptional counter, this is no longer necessary. Extending and
shrinking the tree from and to single entries in root->rnode now does
the right thing when the entry is exceptional, remove that limitation.
Signed-off-by: Johannes Weiner <hannes@xxxxxxxxxxx>
---
mm/filemap.c | 13 +++----------
1 file changed, 3 insertions(+), 10 deletions(-)
diff --git a/mm/filemap.c b/mm/filemap.c
index 438f0b54f8fd..55a3b136a527 100644
--- a/mm/filemap.c
+++ b/mm/filemap.c
@@ -178,19 +178,12 @@ static void page_cache_tree_delete(struct address_space *mapping,
radix_tree_clear_tags(&mapping->page_tree, node, slot);
- if (!node) {
- VM_BUG_ON_PAGE(nr != 1, page);
- /*
- * We need a node to properly account shadow
- * entries. Don't plant any without. XXX
- */
- shadow = NULL;
- }
-
__radix_tree_replace(&mapping->page_tree, node, slot, shadow);
- if (!node)
+ if (!node) {
+ VM_BUG_ON_PAGE(nr != 1, page);
break;
+ }
if (!shadow &&
__radix_tree_delete_node(&mapping->page_tree, node))
--
2.10.1
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@xxxxxxxxx. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>