diff for duplicates of <1531336913.3260.18.camel@HansenPartnership.com> diff --git a/a/1.txt b/N1/1.txt index 15386da..3756978 100644 --- a/a/1.txt +++ b/N1/1.txt @@ -63,10 +63,3 @@ What in your tests is making it harder to recover the memory in the dentry cache? James - - - --- -To unsubscribe from this list: send the line "unsubscribe linux-doc" in -the body of a message to majordomo@vger.kernel.org -More majordomo info at http://vger.kernel.org/majordomo-info.html diff --git a/a/content_digest b/N1/content_digest index 3f70914..f531536 100644 --- a/a/content_digest +++ b/N1/content_digest @@ -95,13 +95,6 @@ "What in your tests is making it harder to recover the memory in the\n" "dentry cache?\n" "\n" - "James\n" - "\n" - "\n" - "\n" - "--\n" - "To unsubscribe from this list: send the line \"unsubscribe linux-doc\" in\n" - "the body of a message to majordomo@vger.kernel.org\n" - More majordomo info at http://vger.kernel.org/majordomo-info.html + James -334dd0260c63ce96ca5d9fd296c1ee7976e5c0c6e02392f0c3c62380d7a3ecaf +52d1afddd0d6ecdd0840414cf92adea106e9a423d2a2eda740edc52418d5dc64
diff --git a/a/1.txt b/N2/1.txt index 15386da..a7b6016 100644 --- a/a/1.txt +++ b/N2/1.txt @@ -22,18 +22,18 @@ On Wed, 2018-07-11 at 15:07 -0400, Waiman Long wrote: > > converging is that one of the goals of the mm subsystem is to > > manage all of our cached objects and to it the negative (and > > positive) dentries simply look like a clean cache of -> > objects. Right at the moment mm manages them in the same way it +> > objects.A A Right at the moment mm manages them in the same way it > > manages all the other caches, a lot of which suffer from the "you > > can cause lots of allocations to artificially grow them" -> > problem. So the main question is why doesn't the current mm -> > control of the caches work well enough for dentries? -> > What are the problems you're seeing that mm should be catching? If +> > problem.A A So the main question is why doesn't the current mm +> > control of the caches work well enough for dentries?A +> > What are the problems you're seeing that mm should be catching?A A If > > you can answer this, then we could get on to whether a separate > > shrinker, cache separation or some fix in mm itself is the right > > answer. > > > > What you say above is based on a conclusion: limiting dentries -> > improves the system performance. What we're asking for is evidence +> > improves the system performance.A A What we're asking for is evidence > > for that conclusion so we can explore whether the same would go for > > any of our other system caches (so do we have a global cache > > management problem or is it only the dentry cache?) @@ -63,10 +63,3 @@ What in your tests is making it harder to recover the memory in the dentry cache? James - - - --- -To unsubscribe from this list: send the line "unsubscribe linux-doc" in -the body of a message to majordomo@vger.kernel.org -More majordomo info at http://vger.kernel.org/majordomo-info.html diff --git a/a/content_digest b/N2/content_digest index 3f70914..d5f2626 100644 --- a/a/content_digest +++ b/N2/content_digest @@ -55,18 +55,18 @@ "> > converging is that one of the goals of the mm subsystem is to\n" "> > manage all of our cached objects and to it the negative (and\n" "> > positive) dentries simply look like a clean cache of\n" - "> > objects.\302\240\302\240Right at the moment mm manages them in the same way it\n" + "> > objects.A A Right at the moment mm manages them in the same way it\n" "> > manages all the other caches, a lot of which suffer from the \"you\n" "> > can cause lots of allocations to artificially grow them\"\n" - "> > problem.\302\240\302\240So the main question is why doesn't the current mm\n" - "> > control of the caches work well enough for dentries?\302\240\n" - "> > What are the problems you're seeing that mm should be catching?\302\240\302\240If\n" + "> > problem.A A So the main question is why doesn't the current mm\n" + "> > control of the caches work well enough for dentries?A \n" + "> > What are the problems you're seeing that mm should be catching?A A If\n" "> > you can answer this, then we could get on to whether a separate\n" "> > shrinker, cache separation or some fix in mm itself is the right\n" "> > answer.\n" "> > \n" "> > What you say above is based on a conclusion: limiting dentries\n" - "> > improves the system performance.\302\240\302\240What we're asking for is evidence\n" + "> > improves the system performance.A A What we're asking for is evidence\n" "> > for that conclusion so we can explore whether the same would go for\n" "> > any of our other system caches (so do we have a global cache\n" "> > management problem or is it only the dentry cache?)\n" @@ -95,13 +95,6 @@ "What in your tests is making it harder to recover the memory in the\n" "dentry cache?\n" "\n" - "James\n" - "\n" - "\n" - "\n" - "--\n" - "To unsubscribe from this list: send the line \"unsubscribe linux-doc\" in\n" - "the body of a message to majordomo@vger.kernel.org\n" - More majordomo info at http://vger.kernel.org/majordomo-info.html + James -334dd0260c63ce96ca5d9fd296c1ee7976e5c0c6e02392f0c3c62380d7a3ecaf +fe8dc675cdce2cade57ed4fc595c70e5374b1cb89324f3c4c9f1a6afd836fc6a
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.