linux-kernel - Re: [RFC][PATCH 5/5] (experimental) chase and free cache only swap

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]

Message-ID: <20090526181359.GB2843@cmpxchg.org>
Date:	Tue, 26 May 2009 20:14:00 +0200
From:	Johannes Weiner <hannes@...xchg.org>
To:	KAMEZAWA Hiroyuki <kamezawa.hiroyu@...fujitsu.com>
Cc:	"linux-mm@...ck.org" <linux-mm@...ck.org>,
	"balbir@...ux.vnet.ibm.com" <balbir@...ux.vnet.ibm.com>,
	"nishimura@....nes.nec.co.jp" <nishimura@....nes.nec.co.jp>,
	"hugh.dickins@...cali.co.uk" <hugh.dickins@...cali.co.uk>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [RFC][PATCH 5/5] (experimental) chase and free cache only swap

On Tue, May 26, 2009 at 12:18:34PM +0900, KAMEZAWA Hiroyuki wrote:
> 
> From: KAMEZAWA Hiroyuki <kamezawa.hiroyu@...fujitsu.com>
> 
> Just a trial/example patch.
> I'd like to consider more. Better implementation idea is welcome.
> 
> When the system does swap-in/swap-out repeatedly, there are 
> cache-only swaps in general.
> Typically,
>  - swapped out in past but on memory now while vm_swap_full() returns true
> pages are cache-only swaps. (swap_map has no references.)
> 
> This cache-only swaps can be an obstacles for smooth page reclaiming.
> Current implemantation is very naive, just scan & free.

I think we can just remove that vm_swap_full() check in do_swap_page()
and try to remove the page from swap cache unconditionally.

If it's still mapped someplace else, we let it cached.  If not, there
is not much use for keeping it around and we free it.

When I removed it and did benchmarks, I couldn't spot any difference
in the timings, though.  Did you measure the benefits of your patch
somehow?

According to the git history tree, vm_swap_full() was initially only
used to aggressively drop cache entries even when they are mapped.

Rik put it into vmscan to reclaim swap cache _at all_ for activated
pages.  But I think unconditionally dropping the cache entry makes
sense if the page gets shuffled around on the LRU list.  Better to
re-allocate a swap slot close to the new LRU buddies on the next scan.

And having this all covered, the need for the scanning your patch does
should be gone, unless I missed something.

	Hannes
--
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/