On Fri, Apr 17, 2015 at 09:17:53AM +1000, Dave Chinner wrote: > On Thu, Apr 16, 2015 at 10:34:13AM -0400, Johannes Weiner wrote: > > On Thu, Apr 16, 2015 at 12:57:36PM +0900, Joonsoo Kim wrote: > > > This causes following success rate regression of phase 1,2 on stress-highalloc > > > benchmark. The situation of phase 1,2 is that many high order allocations are > > > requested while many threads do kernel build in parallel. > > > > Yes, the patch made the shrinkers on multi-zone nodes less aggressive. > > From the changelog: > > > > This changes kswapd behavior, which used to invoke the shrinkers for each > > zone, but with scan ratios gathered from the entire node, resulting in > > meaningless pressure quantities on multi-zone nodes. > > > > So the previous code *did* apply more pressure on the shrinkers, but > > it didn't make any sense. The number of slab objects to scan for each > > scanned LRU page depended on how many zones there were in a node, and > > their relative sizes. So a node with a large DMA32 and a small Normal > > would receive vastly different relative slab pressure than a node with > > only one big zone Normal. That's not something we should revert to. > > > > If we are too weak on objects compared to LRU pages then we should > > adjust DEFAULT_SEEKS or individual shrinker settings. > > Now this thread has my attention. Changing shrinker defaults will > seriously upset the memory balance under load (in unpredictable > ways) so I really don't think we should even consider changing > DEFAULT_SEEKS. > > If there's a shrinker imbalance, we need to understand which > shrinker needs rebalancing, then modify that shrinker's > configuration and then observe the impact this has on the rest of > the system. This means looking at variance of the memory footprint > in steady state, reclaim overshoot and damping rates before steady > state is acheived, etc. Balancing multiple shrinkers (especially > those with dependencies on other caches) under memory > load is a non-trivial undertaking. > > I don't see any evidence that we have a shrinker imbalance, so I > really suspect the problem is "shrinkers aren't doing enough work". > In that case, we need to increase the pressure being generated, not > start fiddling around with shrinker configurations. Okay. I agree. > > > If we think our pressure ratio is accurate but we don't reclaim enough > > compared to our compaction efforts, then any adjustments to improve > > huge page successrate should come from the allocator/compaction side. > > Right - if compaction is failing, then the problem is more likely > that it isn't generating enough pressure, and so the shrinkers > aren't doing the work we are expecting them to do. That's a problem > with compaction, not the shrinkers... Yes, I agree that. I will investigate more on compaction. Thanks. -- 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>