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
| ||
|
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/
Powered by blists - more mailing lists