On Wed, 12 Oct 2011, Satoru Moriya wrote: > >> Also, if we increase the free-page reserves a.k.a min_free_kbytes, > >> the possibility of direct reclaim on other workloads increases. > >> I think it's a bad side effect. > > > > extra_free_kbytes has the same side-effect. > > I don't think so. If we make low watermark bigger to increase > free-page reserves by extra_free_kbytes, the possibility of > direct reclaim on other workload does not increase directly > because min watermark is not changed. I think the point was that extra_free_kbytes needs to be tuned to cover at least the amount of memory of the largest allocation burst or it doesn't help to prevent latencies for rt threads and, depending on how the implementation of the VM evolves, that value may change significantly over time from kernel release to kernel release. For example, if we were to merge Con's patch so kswapd operates at a much higher priority for rt threads later on for another issue, it may significantly reduce the need for extra_free_kbytes to be set as high as it is. Everybody who is setting this in init scripts, though, will continue to set the value because they have no reason to believe it should be changed. Then, we have users who start to use the tunable after Con's patch has been merged and now we have widely different settings for the same tunable and it can never be obsoleted because everybody is using it but for different historic reasons. This is why I nack'd the patch originally: it will never be removed, it is widely misunderstood, and is tied directly to the implementation of reclaim which will change over time. -- 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>