On Tue, 11 Oct 2011, Satoru Moriya wrote: > > I also > > think that it will cause regressions on other cpu intensive workloads > > that don't require this extra freed memory because it works as a > > global heuristic and is not tied to any specific application. > > It's yes and no. It may cause regressions on the workloads due to > less amount of available memory. But it may improve the workloads' > performance because they can avoid direct reclaim due to extra > free memory. > There's only a memory-availability regression if background reclaim is actually triggered in the first place, i.e. extra_free_kbytes doesn't affect the watermarks themselves when reclaim is started but rather causes it to, when set, reclaim more memory than otherwise. That's not really what I was referring to; I was referring to cpu intensive workloads that now incur a regression because kswapd is now doing more work (potentially a significant amount of work since extra_free_kbytes is unbounded) on shared machines. These applications may not be allocating memory at all and now they incur a performance penalty because kswapd is taking away one of their cores. In other words, I think it's a fine solution if you're running a single application with very bursty memory allocations so you need to reclaim more memory when low, but that solution is troublesome if it comes at the penalty of other applications and that's a direct consequence of it being a global tunable. I'd much rather identify memory allocations in the kernel that causing the pain here and mitigate it by (i) attempting to sanely rate limit those allocations, (ii) preallocate at least a partial amount of those allocations ahead of time so avoid significant reclaim all at one, or (iii) annotate memory allocations with such potential so that the page allocator can add this reclaim bonus itself only in these conditions. > Of course if one doesn't need extra free memory, one can turn it > off. I think we can add this feature to cgroup if we want to set > it for any specific process or process group. (Before that we > need to implement min_free_kbytes for cgroup and the implementation > of extra free kbytes strongly depends on it.) > That would allow you to only reclaim additional memory when certain applications tirgger it, but it's not actually a solution since another task can hit a zone's low watermark and kick kswapd and then the bursty memory allocations happen immediately following that and doesn't actually do anything because kswapd was already running. So I disagree, as I did when per-cgroup watermark tunables were proposed, that watermarks should be changed for a subset of applications unless you guarantee memory isolation such that that subset of applications has exclusive access to the memory zones being tuned. -- 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/ . Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/ Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>