On 01/18/2012 09:25 PM, KAMEZAWA Hiroyuki wrote:

On Wed, 18 Jan 2012 09:17:17 -0500
Rik van Riel[off-list ref]  wrote:

quoted

On 01/17/2012 07:18 PM, KAMEZAWA Hiroyuki wrote:

quoted

On Wed, 18 Jan 2012 08:08:01 +0900
Minchan Kim[off-list ref]   wrote:

quoted

quoted

quoted

quoted

2. can't we measure page-in/page-out distance by recording something ?

I can't understand your point. What's relation does it with swapout prevent?

If distance between pageout ->   pagein is short, it means thrashing.
For example, recoding the timestamp when the page(mapping, index) was
paged-out, and check it at page-in.

Our goal is prevent swapout. When we found thrashing, it's too late.

If you want to prevent swap-out, don't swapon any. That's all.
Then, you can check the number of FILE_CACHE and have threshold.

I think you are getting hung up on a word here.

As I understand it, the goal is to push out the point where
we start doing heavier swap IO, allowing us to overcommit
memory more heavily before things start really slowing down.

Yes.

Hmm, considering that the issue is slow down,

time values as

- 'cpu time used for memory reclaim'
- 'latency of page allocation'
- 'application execution speed' ?

may be a better score to see rather than just seeing lru's stat.

I believe those all qualify as "too late".

We want to prevent things from becoming bad, for as long
as we (easily) can.

-- 
All rights reversed

--
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 internet charges in Canada: sign http://stopthemeter.ca/
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>