On 01/07/2011 05:39 PM, David Rientjes wrote: > The semantics of any watermark is to trigger events to happen at a > specific level, so they should be static with respect to a frame of > reference (which in the VM case is the min watermark with respect to the > size of the zone). If you're going to adjust the min watermark, it's then > _mandatory_ to adjust the others to that frame of reference, you shouldn't > need to tune them independently. Currently watermark[low,high] are set by following calculation (lowmem case). watermark[low] = watermark[min] * 1.25 watermark[high] = watermark[min] * 1.5 So the difference between watermarks are following: min <-- min/4 --> low <-- min/4 --> high I think the differences, "min/4", are too small in my case. Of course I can make them bigger if I set min_free_kbytes to bigger value. But it means kernel keeps more free memory for PF_MEMALLOC case unnecessarily. So I suggest changing coefficients(1.25, 1.5). Also it's better to make them accessible from user space to tune in response to application requirements. > The problem that Satoru is reporting probably has nothing to do with the > watermarks themselves but probably requires more aggressive action by > kswapd and/or memory compaction. More aggressive action may reduce the possibility of the problem reported. But we can't avoid the problem completely because applications may allocate/access faster than reclaiming/compaction. -- 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/ . Fight unfair telecom policy in Canada: sign http://dissolvethecrtc.ca/ Don't email: <a href