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@xxxxxxxxxxxxxx> 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 from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/