linux-kernel - Re: mm: used-once mapped file page detection

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] [thread-next>] [day] [month] [year] [list]

Date:	Wed, 24 Feb 2010 13:39:46 -0800
From:	Andrew Morton <akpm@...ux-foundation.org>
To:	Johannes Weiner <hannes@...xchg.org>
Cc:	KOSAKI Motohiro <kosaki.motohiro@...fujitsu.com>,
	Minchan Kim <minchan.kim@...il.com>,
	Rik van Riel <riel@...hat.com>, linux-mm@...ck.org,
	linux-kernel@...r.kernel.org
Subject: Re: mm: used-once mapped file page detection

On Mon, 22 Feb 2010 20:49:07 +0100 Johannes Weiner <hannes@...xchg.org> wrote:

> this is the second submission of the used-once mapped file page
> detection patch.
> 
> It is meant to help workloads with large amounts of shortly used file
> mappings, like rtorrent hashing a file or git when dealing with loose
> objects (git gc on a bigger site?).
> 
> Right now, the VM activates referenced mapped file pages on first
> encounter on the inactive list and it takes a full memory cycle to
> reclaim them again.  When those pages dominate memory, the system
> no longer has a meaningful notion of 'working set' and is required
> to give up the active list to make reclaim progress.  Obviously,
> this results in rather bad scanning latencies and the wrong pages
> being reclaimed.
> 
> This patch makes the VM be more careful about activating mapped file
> pages in the first place.  The minimum granted lifetime without
> another memory access becomes an inactive list cycle instead of the
> full memory cycle, which is more natural given the mentioned loads.

iirc from a long time ago, the insta-activation of mapped pages was
done because people were getting peeved about having their interactive
applications (X, browser, etc) getting paged out, and bumping the pages
immediately was found to help with this subjective problem.

So it was a latency issue more than a throughput issue.  I wouldn't be
surprised if we get some complaints from people for the same reasons as
a result of this patch.

I guess that during the evaluation period of this change, it would be
useful to have a /proc knob which people can toggle to revert to the
old behaviour.  So they can verify that this patchset was indeed the
cause of the deterioration, and so they can easily quantify any
deterioration?
--
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/