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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-Id: <20100902185926.B64E.A69D9226@jp.fujitsu.com>
Date:	Thu,  2 Sep 2010 19:04:50 +0900 (JST)
From:	KOSAKI Motohiro <kosaki.motohiro@...fujitsu.com>
To:	Minchan Kim <minchan.kim@...il.com>
Cc:	kosaki.motohiro@...fujitsu.com, Hugh Dickins <hughd@...gle.com>,
	Johannes Weiner <hannes@...xchg.org>,
	Rik van Riel <riel@...hat.com>,
	LKML <linux-kernel@...r.kernel.org>,
	linux-mm <linux-mm@...ck.org>,
	Andrew Morton <akpm@...ux-foundation.org>
Subject: Re: [PATCH] vmscan,tmpfs: treat used once pages on tmpfs as used once

> Hi KOSAKI,
> 
> On Wed, Sep 1, 2010 at 10:37 AM, KOSAKI Motohiro
> <kosaki.motohiro@...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 from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/