On Thu, 21 Oct 2010, Andrew Morton wrote: > > Do you know what the point of calling slab_shrink() per zone in one > > location (kswapd) vs. for each reclaim pass in direct reclaim is? > > No. As I said, I don't recall the thinking behind it. And I (and > apparently only I) made the effort to find out. > > It could be in the very old email archives. It would be a lot of work > to find it if so. Which is why we should put things in comments and > changelogs. With great diligence. So we don't cause regressions five > years later. I dont think there can be any point in calling a reclaim functions thrice given that the reclaim function has logic to fine tune the pressure to be put on a cache. It will do 3 times what only should have been done once. If someone would have intentionally wanted this then the logic to tune the pressure in the slab reclaim function would have been changed. > > But maybe its better to throw the two changes together to make this one > > patch for per node slab reclaim support. > > It could be that the patch improves behaviour on smaller machines. Or > worsens it or, more likely, has no discernable effect. Likely no discernable effect since it only occurs for background reclaim where it would be barely noticeable. Direct reclaim is something else. There we have it outside of the loop over zones being called only once per reclaim pass. > But for heavens sake we shouldn't go patching people's kernels when we > don't know what the effect of our change is! Is this controversial? We need to understand the code first. If we do not know what the effect of the change is then our knowledge about how the kernel operates is deficient and we are not able to control the code. Certainly tests need to be run but first lets hash out our understanding of the code. -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@xxxxxxxxxx For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>