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@kvack.org.  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=mailto:"dont@kvack.org"> email@kvack.org </a>