diff for duplicates of <20111230150421.GE15729@suse.de> diff --git a/a/1.txt b/N1/1.txt index c1e8722..20e337a 100644 --- a/a/1.txt +++ b/N1/1.txt @@ -20,7 +20,7 @@ Indeed. > > I'll try to explain why I believe we end up succeeding in most cases: > -> For CONFIG_CPUMASK_OFFSTACK=n - case there is no allocation, so there +> For CONFIG_CPUMASK_OFFSTACK=n - case there is no allocation, so there > is no problem. > @@ -39,19 +39,19 @@ which can be called from some heavy stack usage paths. However, as we have already used direct reclaim and that is a heavy stack user, it probably is not as serious a problem. -> For CONFIG_CPUMASK_OFFSTACK=y but when we got to drain_all_pages from +> For CONFIG_CPUMASK_OFFSTACK=y but when we got to drain_all_pages from > the memory > hotplug or the memory failure code path (the code other code path that > call drain_all_pages), -> there is no inherent memory pressure, so we should be OK. +> there is no inherent memory pressure, so we should be OK. > It's the memory failure code path after direct reclaim failed. How can you say there is no inherent memory pressure? -> If we did get to drain_all_pages from direct reclaim, but the cpumask +> If we did get to drain_all_pages from direct reclaim, but the cpumask > slab has an object in the -> slab (or partial pages in the case of slub), then we never hit the +> slab (or partial pages in the case of slub), then we never hit the > page allocator so all is well, I believe. > @@ -62,13 +62,13 @@ that it is likely to be rare. > So this leaves us with being called from the direct reclaim path, when > the cpumask slab has no -> object or partial pages and it needs to hit the page allocator. If we +> object or partial pages and it needs to hit the page allocator. If we > hit direct page relcaim, the original -> allocation was not atomic , otherwise we would not have hit direct -> page reclaim. The cpumask allocation -> however, is atomic, so we have broader allocation options - allocate -> high, allocate outside our cpuset -> etc. and there is a reasonable chance the cpumask allocation can +> allocation was not atomic , otherwise we would not have hit direct +> page reclaim. The cpumask allocation +> however, is atomic, so we have broader allocation options - allocate +> high, allocate outside our cpuset +> etc. and there is a reasonable chance the cpumask allocation can > succeed even if the original allocation > ended up in direct reclaim. > @@ -93,7 +93,7 @@ Ok, I accept that it will fail gracefully. > > > Related to that, calling into the page allocator again for -> > zalloc_cpumask_var is not cheap. Does reducing the number of IPIs +> > zalloc_cpumask_var is not cheap. Does reducing the number of IPIs > > offset the cost of calling into the allocator again? How often does it > > offset the cost and how often does it end up costing more? I guess that > > would heavily depend on the number of CPUs and how many of them have @@ -115,7 +115,7 @@ It's the CPUMASK_OFFSTACK=y case I worry about as it is enabled on at least one server-orientated distribution and probably more. > The way I see it, the use cases where you end up profiting from the code -> are the same places you also pay. Having lots of CPU is what forced you +> are the same places you also pay. Having lots of CPU is what forced you > to use CPUMASK_OFFSTACK and pay that extra allocation but > then it is exactly when you have lots of CPUs that the code pays off. > @@ -124,12 +124,12 @@ at least one server-orientated distribution and probably more. > > performance. > > -> Thanks! it is good to hear it is not completely off the wall :-) +> Thanks! it is good to hear it is not completely off the wall :-) > > I think of it more of as a CPU isolation feature then pure performance. > If you have a system with a couple of dozens of CPUs (Tilera, SGI, Cavium > or the various virtual NUMA folks) you tend to want to break up the system -> into sets of CPUs that work of separate tasks. +> into sets of CPUs that work of separate tasks. > Even with the CPUs isolated, how often is it the case that many of @@ -140,10 +140,10 @@ many cases the exact same number of IPIs will be used but with the additional cost of allocating a cpumask. > It is very annoying when a memory allocation failure in a task allocated to a -> small set of 4 CPUs yanks out all the rest of your 4,092 CPUs working on -> something completely different out of their cache warm happy existence into -> the cache cold reality of an IPI, or worse yet yanks all those CPUs from the -> nirvana of idle C-states saving power just to discover that no, they don't +> small set of 4 CPUs yanks out all the rest of your 4,092 CPUs working on +> something completely different out of their cache warm happy existence into +> the cache cold reality of an IPI, or worse yet yanks all those CPUs from the +> nirvana of idle C-states saving power just to discover that no, they don't > actually have anything to do. :-) > > I do believe the overhead for the cases without a lot of CPUs is quite minimal. @@ -164,10 +164,3 @@ number of times IPIs are globally transmitted by X% for some workload. -- Mel Gorman SUSE Labs - --- -To unsubscribe, send a message with 'unsubscribe linux-mm' in -the body to majordomo@kvack.org. For more info on Linux MM, -see: http://www.linux-mm.org/ . -Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/ -Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a> diff --git a/a/content_digest b/N1/content_digest index f903ceb..899b3d8 100644 --- a/a/content_digest +++ b/N1/content_digest @@ -41,7 +41,7 @@ "> \n" "> I'll try to explain why I believe we end up succeeding in most cases:\n" "> \n" - "> For CONFIG_CPUMASK_OFFSTACK=n - case there is no allocation, so there\n" + "> For\302\240CONFIG_CPUMASK_OFFSTACK=n - case there is no allocation, so there\n" "> is no problem.\n" "> \n" "\n" @@ -60,19 +60,19 @@ "we have already used direct reclaim and that is a heavy stack user,\n" "it probably is not as serious a problem.\n" "\n" - "> For CONFIG_CPUMASK_OFFSTACK=y but when we got to drain_all_pages from\n" + "> For\302\240CONFIG_CPUMASK_OFFSTACK=y but when\302\240we got to drain_all_pages from\n" "> the memory\n" "> hotplug or the memory failure code path (the code other code path that\n" "> call drain_all_pages),\n" - "> there is no inherent memory pressure, so we should be OK.\n" + "> there is \302\240no inherent memory pressure, so we should be OK.\n" "> \n" "\n" "It's the memory failure code path after direct reclaim failed. How\n" "can you say there is no inherent memory pressure?\n" "\n" - "> If we did get to drain_all_pages from direct reclaim, but the cpumask\n" + "> If we did get to drain_all_pages \302\240from direct reclaim, but the cpumask\n" "> slab has an object in the\n" - "> slab (or partial pages in the case of slub), then we never hit the\n" + "> slab (or partial pages in the case \302\240of slub), then we never hit the\n" "> page allocator so all is well, I believe.\n" "> \n" "\n" @@ -83,13 +83,13 @@ "\n" "> So this leaves us with being called from the direct reclaim path, when\n" "> the cpumask slab has no\n" - "> object or partial pages and it needs to hit the page allocator. If we\n" + "> object or partial pages and it needs to hit the page allocator. \302\240If we\n" "> hit direct page relcaim, the original\n" - "> allocation was not atomic , otherwise we would not have hit direct\n" - "> page reclaim. The cpumask allocation\n" - "> however, is atomic, so we have broader allocation options - allocate\n" - "> high, allocate outside our cpuset\n" - "> etc. and there is a reasonable chance the cpumask allocation can\n" + "> allocation was not atomic ,\302\240otherwise we would not have \302\240hit direct\n" + "> page reclaim. \302\240The cpumask allocation\n" + "> however, \302\240is atomic,\302\240so we have broader allocation\302\240options - \302\240allocate\n" + "> high, \302\240allocate outside our cpuset\n" + "> etc. and \302\240there is a\302\240reasonable\302\240chance the cpumask\302\240allocation can\n" "> succeed even if the original allocation\n" "> ended up in direct reclaim.\n" "> \n" @@ -114,7 +114,7 @@ "\n" "> \n" "> > Related to that, calling into the page allocator again for\n" - "> > zalloc_cpumask_var is not cheap. Does reducing the number of IPIs\n" + "> > zalloc_cpumask_var is not cheap. \302\240Does reducing the number of IPIs\n" "> > offset the cost of calling into the allocator again? How often does it\n" "> > offset the cost and how often does it end up costing more? I guess that\n" "> > would heavily depend on the number of CPUs and how many of them have\n" @@ -136,7 +136,7 @@ "at least one server-orientated distribution and probably more.\n" "\n" "> The way I see it, the use cases where you end up profiting from the code\n" - "> are the same places you also pay. Having lots of CPU is what forced you\n" + "> are the same places you also pay. Having lots of CPU is what\302\240forced you\n" "> to use CPUMASK_OFFSTACK and pay that extra allocation but\n" "> then it is exactly when you have lots of CPUs that the code pays off.\n" "> \n" @@ -145,12 +145,12 @@ "> > performance.\n" "> \n" "> \n" - "> Thanks! it is good to hear it is not completely off the wall :-)\n" + "> Thanks! it is good to hear it is not\302\240completely\302\240off the wall :-)\n" "> \n" "> I think of it more of as a CPU isolation feature then pure performance.\n" "> If you have a system with a couple of dozens of CPUs (Tilera, SGI, Cavium\n" "> or the various virtual NUMA folks) you tend to want to break up the system\n" - "> into sets of CPUs that work of separate tasks.\n" + "> into sets of CPUs that work of\302\240separate\302\240tasks.\n" "> \n" "\n" "Even with the CPUs isolated, how often is it the case that many of\n" @@ -161,10 +161,10 @@ "additional cost of allocating a cpumask.\n" "\n" "> It is very annoying when a memory allocation failure in a task allocated to a\n" - "> small set of 4 CPUs yanks out all the rest of your 4,092 CPUs working on\n" - "> something completely different out of their cache warm happy existence into\n" - "> the cache cold reality of an IPI, or worse yet yanks all those CPUs from the\n" - "> nirvana of idle C-states saving power just to discover that no, they don't\n" + "> small set of 4 CPUs\302\240yanks out all the rest of your 4,092 CPUs working on\n" + "> something\302\240completely\302\240different out of their cache warm happy existence into\n" + "> the cache cold\302\240reality\302\240of\302\240an IPI, or worse\302\240yet yanks all those CPUs from the\n" + "> nirvana of idle C-states saving power just to\302\240discover that no, they don't\n" "> actually have anything to do. :-)\n" "> \n" "> I do believe the overhead for the cases without a lot of CPUs is quite minimal.\n" @@ -184,13 +184,6 @@ "\n" "-- \n" "Mel Gorman\n" - "SUSE Labs\n" - "\n" - "--\n" - "To unsubscribe, send a message with 'unsubscribe linux-mm' in\n" - "the body to majordomo@kvack.org. For more info on Linux MM,\n" - "see: http://www.linux-mm.org/ .\n" - "Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/\n" - "Don't email: <a href=mailto:\"dont@kvack.org\"> email@kvack.org </a>" + SUSE Labs -a4308b7b1471c6b5e3fa22cf6d2ed3dc9d9e2ef1b7197bc8a33e70a71f036d74 +f6dfab348eb5bff936ad1f2c5f2688522c28d0c34e3eae2d74ff29371a47bd47
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.