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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ