diff for duplicates of <1531411494.18255.6.camel@HansenPartnership.com> diff --git a/a/1.txt b/N1/1.txt index 85f2983..4deabd0 100644 --- a/a/1.txt +++ b/N1/1.txt @@ -126,9 +126,4 @@ James > > Cheers, > Longman -> - --- -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 59e1f56..a58c0da 100644 --- a/a/content_digest +++ b/N1/content_digest @@ -161,11 +161,6 @@ "> \n" "> Cheers,\n" "> Longman\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 + > -815264756c32730b4ad5c905acc1fe3a7981b6581c255473cd1451818ea50a8a +2efb8653b9f4bdb651534b864bdb87cdd10878f8b7f77a5fa2b781abd9381c97
diff --git a/a/1.txt b/N2/1.txt index 85f2983..9e1a10f 100644 --- a/a/1.txt +++ b/N2/1.txt @@ -29,22 +29,22 @@ On Thu, 2018-07-12 at 11:54 -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 +> > > > 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? +> > > > 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? If +> > > > 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 +> > > > 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 @@ -64,18 +64,18 @@ On Thu, 2018-07-12 at 11:54 -0400, Waiman Long wrote: > > > memory consumed by dentries is a very small portion of the system > > > memory. > > -> > OK, can we poke on only this point for a while? Linux never really +> > OK, can we poke on only this point for a while?A A Linux never really > > has > > any "available memory": pretty much as soon as you boot up the > > system > > will consume all your free memory for some type of cache (usually > > the -> > page cache which got filled during boot). The expectation is that +> > page cache which got filled during boot).A A The expectation is that > > in a > > steady, running, state the system is using almost all available > > memory > > for caching something ... if it's not negative dentries it will be -> > something else. The mm assumption is that clean cache is so cheap +> > something else.A A The mm assumption is that clean cache is so cheap > > to > > recover that it's almost equivalent to free memory and your patch > > is @@ -83,7 +83,7 @@ On Thu, 2018-07-12 at 11:54 -0400, Waiman Long wrote: > > cache. > > > > So, why can't we treat the dentry cache as equivalent to free -> > memory? +> > memory?A > > What in your tests is making it harder to recover the memory in the > > dentry cache? > > @@ -126,9 +126,4 @@ James > > Cheers, > Longman -> - --- -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 59e1f56..38ca91f 100644 --- a/a/content_digest +++ b/N2/content_digest @@ -64,22 +64,22 @@ "> > > > 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\n" + "> > > > objects.A A Right at the moment mm manages them in the same way\n" "> > > > it\n" "> > > > manages all the other caches, a lot of which suffer from the\n" "> > > > \"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" + "> > > > 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\n" - "> > > > catching?\302\240\302\240If\n" + "> > > > 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\n" "> > > > 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\n" + "> > > > improves the system performance.A A What we're asking for is\n" "> > > > evidence\n" "> > > > for that conclusion so we can explore whether the same would go\n" "> > > > for\n" @@ -99,18 +99,18 @@ "> > > memory consumed by dentries is a very small portion of the system\n" "> > > memory.\n" "> > \n" - "> > OK, can we poke on only this point for a while?\302\240\302\240Linux never really\n" + "> > OK, can we poke on only this point for a while?A A Linux never really\n" "> > has\n" "> > any \"available memory\": pretty much as soon as you boot up the\n" "> > system\n" "> > will consume all your free memory for some type of cache (usually\n" "> > the\n" - "> > page cache which got filled during boot).\302\240\302\240The expectation is that\n" + "> > page cache which got filled during boot).A A The expectation is that\n" "> > in a\n" "> > steady, running, state the system is using almost all available\n" "> > memory\n" "> > for caching something ... if it's not negative dentries it will be\n" - "> > something else.\302\240\302\240The mm assumption is that clean cache is so cheap\n" + "> > something else.A A The mm assumption is that clean cache is so cheap\n" "> > to\n" "> > recover that it's almost equivalent to free memory and your patch\n" "> > is\n" @@ -118,7 +118,7 @@ "> > cache.\n" "> > \n" "> > So, why can't we treat the dentry cache as equivalent to free\n" - "> > memory?\302\240\n" + "> > memory?A \n" "> > What in your tests is making it harder to recover the memory in the\n" "> > dentry cache?\n" "> > \n" @@ -161,11 +161,6 @@ "> \n" "> Cheers,\n" "> Longman\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 + > -815264756c32730b4ad5c905acc1fe3a7981b6581c255473cd1451818ea50a8a +94cfece1ed2200fce1025f88c87d2e05d41edf760125ab11a12a3e93290251e5
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.