On Wed, 12 Oct 2011, Satoru Moriya wrote: > > 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 > > Right. In enterprise area, we strictly test the system we build > again and again before we release it. In that situation, we can > set extra_free_kbytes appropriately based on system's requirements > and/or specifications etc. > You would also need to guarantee that min_free_kbytes isn't subsequently changed because that would change the value that extra_free_kbytes would need to preserve the same exclusive access to memory that the rt threads would have without increasing it. > I understand what you concern. But in some area such as banking, > stock exchange, train/power/plant control sysemts etc this kind > of tunable is welcomed because they can tune their systems at > their own risk. > You haven't tried the patch that increases the priority of kswapd when such a latency sensitive thread triggers background reclaim? -- 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>