[PATCH] vmscan,tmpfs: treat used once pages on tmpfs as used once

[PATCH] vmscan,tmpfs: treat used once pages on tmpfs as used once

[KOSAKI Motohiro]

When a page has PG_referenced, shrink_page_list() discard it only
if it is no dirty. This rule works completely fine if the backend
filesystem is regular one. PG_dirty is good signal that it was used
recently because flusher thread clean pages periodically. In addition,
page writeback is costly rather than simple page discard.

However, When a page is on tmpfs, this heuristic don't works because
flusher thread don't writeback tmpfs pages. then, tmpfs pages always
rotate lru twice at least and it makes unnecessary lru churn. Merely
tmpfs streaming io shouldn't cause large anonymous page swap-out.

This patch remove this unncessary reclaim bonus of tmpfs pages.

Cc: Hugh Dickins <hughd@google.com>
Cc: Johannes Weiner <hannes@cmpxchg.org>
Cc: Rik van Riel <riel@redhat.com>
Signed-off-by: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
---
 mm/vmscan.c |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/mm/vmscan.c b/mm/vmscan.c
index 1919d8a..aba3402 100644
--- a/mm/vmscan.c
+++ b/mm/vmscan.c
@@ -617,7 +617,7 @@ static enum page_references page_check_references(struct page *page,
 	}
 
 	/* Reclaim if clean, defer dirty pages to writeback */
-	if (referenced_page)
+	if (referenced_page && !PageSwapBacked(page))
 		return PAGEREF_RECLAIM_CLEAN;
 
 	return PAGEREF_RECLAIM;
-- 
1.6.5.2



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

Re: [PATCH] vmscan,tmpfs: treat used once pages on tmpfs as used once

[Johannes Weiner]

On Wed, Sep 01, 2010 at 10:37:49AM +0900, KOSAKI Motohiro wrote:
> When a page has PG_referenced, shrink_page_list() discard it only
> if it is no dirty. This rule works completely fine if the backend
> filesystem is regular one. PG_dirty is good signal that it was used
> recently because flusher thread clean pages periodically. In addition,
> page writeback is costly rather than simple page discard.
> 
> However, When a page is on tmpfs, this heuristic don't works because
> flusher thread don't writeback tmpfs pages. then, tmpfs pages always
> rotate lru twice at least and it makes unnecessary lru churn. Merely
> tmpfs streaming io shouldn't cause large anonymous page swap-out.
> 
> This patch remove this unncessary reclaim bonus of tmpfs pages.
> 
> Cc: Hugh Dickins <hughd@google.com>
> Cc: Johannes Weiner <hannes@cmpxchg.org>
> Cc: Rik van Riel <riel@redhat.com>
> Signed-off-by: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>

Reviewed-by: Johannes Weiner <hannes@cmpxchg.org>

> ---
>  mm/vmscan.c |    2 +-
>  1 files changed, 1 insertions(+), 1 deletions(-)
> 
> diff --git a/mm/vmscan.c b/mm/vmscan.c
> index 1919d8a..aba3402 100644
> --- a/mm/vmscan.c
> +++ b/mm/vmscan.c
> @@ -617,7 +617,7 @@ static enum page_references page_check_references(struct page *page,
>  	}
>  
>  	/* Reclaim if clean, defer dirty pages to writeback */
> -	if (referenced_page)
> +	if (referenced_page && !PageSwapBacked(page))
>  		return PAGEREF_RECLAIM_CLEAN;
>  
>  	return PAGEREF_RECLAIM;
> -- 
> 1.6.5.2
> 
> 
> 
> 

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

Re: [PATCH] vmscan,tmpfs: treat used once pages on tmpfs as used once

[Rik van Riel]

On 08/31/2010 09:37 PM, KOSAKI Motohiro wrote:
> When a page has PG_referenced, shrink_page_list() discard it only
> if it is no dirty. This rule works completely fine if the backend
> filesystem is regular one. PG_dirty is good signal that it was used
> recently because flusher thread clean pages periodically. In addition,
> page writeback is costly rather than simple page discard.
>
> However, When a page is on tmpfs, this heuristic don't works because
> flusher thread don't writeback tmpfs pages. then, tmpfs pages always
> rotate lru twice at least and it makes unnecessary lru churn. Merely
> tmpfs streaming io shouldn't cause large anonymous page swap-out.
>
> This patch remove this unncessary reclaim bonus of tmpfs pages.
>
> Cc: Hugh Dickins<hughd@google.com>
> Cc: Johannes Weiner<hannes@cmpxchg.org>
> Cc: Rik van Riel<riel@redhat.com>
> Signed-off-by: KOSAKI Motohiro<kosaki.motohiro@jp.fujitsu.com>

Reviewed-by: Rik van Riel <riel@redhat.com>

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

Re: [PATCH] vmscan,tmpfs: treat used once pages on tmpfs as used once

[Minchan Kim]

Hi KOSAKI,

On Wed, Sep 1, 2010 at 10:37 AM, KOSAKI Motohiro
<kosaki.motohiro@jp.fujitsu.com> wrote:
> When a page has PG_referenced, shrink_page_list() discard it only
> if it is no dirty. This rule works completely fine if the backend
> filesystem is regular one. PG_dirty is good signal that it was used
> recently because flusher thread clean pages periodically. In addition,
> page writeback is costly rather than simple page discard.
>
> However, When a page is on tmpfs, this heuristic don't works because
> flusher thread don't writeback tmpfs pages. then, tmpfs pages always
> rotate lru twice at least and it makes unnecessary lru churn. Merely
> tmpfs streaming io shouldn't cause large anonymous page swap-out.

It seem to make sense.
But the why admin use tmps is to keep the contents in memory as far as
possible than other's file system.
But this patch has a possibility for tmpfs pages to reclaim early than
old behavior.

I admit this routine's goal is not to protect tmpfs page from too early reclaim.
But at least, it would have affected until now.
If it is, we might need other demotion prevent mechanism to protect tmpfs pages.
Is split LRU enough? (I mean we consider tmpfs pages as anonymous
which is hard to reclaim than file backed pages).

I don't mean to oppose this patch and I don't have a any number to
insist on my opinion.
Just what I want is that let's think about it more carefully and
listen other's opinions. :)

Thanks for good suggestion.

-- 
Kind regards,
Minchan Kim

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

Re: [PATCH] vmscan,tmpfs: treat used once pages on tmpfs as used once

[KOSAKI Motohiro]

> Hi KOSAKI,
> 
> On Wed, Sep 1, 2010 at 10:37 AM, KOSAKI Motohiro
> <kosaki.motohiro@jp.fujitsu.com> wrote:
> > When a page has PG_referenced, shrink_page_list() discard it only
> > if it is no dirty. This rule works completely fine if the backend
> > filesystem is regular one. PG_dirty is good signal that it was used
> > recently because flusher thread clean pages periodically. In addition,
> > page writeback is costly rather than simple page discard.
> >
> > However, When a page is on tmpfs, this heuristic don't works because
> > flusher thread don't writeback tmpfs pages. then, tmpfs pages always
> > rotate lru twice at least and it makes unnecessary lru churn. Merely
> > tmpfs streaming io shouldn't cause large anonymous page swap-out.
> 
> It seem to make sense.
> But the why admin use tmps is to keep the contents in memory as far as
> possible than other's file system.
> But this patch has a possibility for tmpfs pages to reclaim early than
> old behavior.
> 
> I admit this routine's goal is not to protect tmpfs page from too early reclaim.
> But at least, it would have affected until now.
> If it is, we might need other demotion prevent mechanism to protect tmpfs pages.
> Is split LRU enough? (I mean we consider tmpfs pages as anonymous
> which is hard to reclaim than file backed pages).

I think so. Split-LRU provide priotize anon rather than regular file. and old behavior is
obvious strange. streaming io tolerance is one of fundamental VM requirement.
So, I think current one is only historical reason.


> 
> I don't mean to oppose this patch and I don't have a any number to
> insist on my opinion.
> Just what I want is that let's think about it more carefully and
> listen other's opinions. :)
> 
> Thanks for good suggestion.
> 
> -- 
> Kind regards,
> Minchan Kim



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