linux-kernel - Re: [PATCH] mm: swap prefetch improvements

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: <20070521100320.GA1801@elte.hu>
Date:	Mon, 21 May 2007 12:03:20 +0200
From:	Ingo Molnar <mingo@...e.hu>
To:	Con Kolivas <kernel@...ivas.org>
Cc:	Nick Piggin <nickpiggin@...oo.com.au>,
	Ray Lee <ray-lk@...rabbit.org>, ck list <ck@....kolivas.org>,
	Andrew Morton <akpm@...ux-foundation.org>,
	linux-kernel@...r.kernel.org, linux-mm@...ck.org
Subject: Re: [PATCH] mm: swap prefetch improvements

* Con Kolivas <kernel@...ivas.org> wrote:

> It turns out that fixing swap prefetch was not that hard to fix and 
> improve upon, and since Andrew hasn't dropped swap prefetch, instead 
> here are a swag of fixes and improvements, [...]

it's a reliable win on my testbox too:

 # echo 1 > /proc/sys/vm/swap_prefetch
 # ./sp_tester
 Ram 1019540000  Swap 4096564000
 Total ram to be malloced: 1529310000 bytes
 Starting first malloc of 764655000 bytes
 Starting 1st read of first malloc
 Touching this much ram takes 4393 milliseconds
 Starting second malloc of 764655000 bytes
 Completed second malloc and free
 Sleeping for 600 seconds
 Important part - starting reread of first malloc
 Completed read of first malloc
 Timed portion 30279 milliseconds

versus:

 # echo 0 > /proc/sys/vm/swap_prefetch
 # ./sp_tester
 [...]

 Timed portion 36605 milliseconds

i've repeated these tests to make sure it's a stable win and indeed it 
is:

   # swap-prefetch-on:

   Timed portion 29704 milliseconds

   # swap-prefetch-off:

   Timed portion 34863 milliseconds

Nice work Con!

A suggestion for improvement: right now swap-prefetch does a small bit 
of swapin every 5 seconds and stays idle inbetween. Could this perhaps 
be made more agressive (optionally perhaps), if the system is not 
swapping otherwise? If block-IO level instrumentation is needed to 
determine idleness of block IO then that is justified too i think.

Another suggestion: swap-prefetch seems to be doing all the right 
decisions in the sp_test.c case - so would it be possible to add 
statistics so that it could be verified how much of the swapped-in pages 
were indeed a 'hit' - and how many were recycled without them being 
reused? That could give a reliable, objective metric about how efficient 
swap-prefetch is in any workload.

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