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, 16 Aug 2010 11:07:37 +0900 From: Naoya Horiguchi <n-horiguchi@...jp.nec.com> To: Jeff Moyer <jmoyer@...hat.com> Cc: Christoph Lameter <cl@...ux-foundation.org>, Andi Kleen <andi@...stfloor.org>, Andrew Morton <akpm@...ux-foundation.org>, Mel Gorman <mel@....ul.ie>, Wu Fengguang <fengguang.wu@...el.com>, "Jun'ichi Nomura" <j-nomura@...jp.nec.com>, linux-mm <linux-mm@...ck.org>, LKML <linux-kernel@...r.kernel.org>, Andrea Arcangeli <aarcange@...hat.com> Subject: Re: [RFC] [PATCH 2/4] dio: add page locking for direct I/O Hi, On Thu, Aug 12, 2010 at 09:42:21AM -0400, Jeff Moyer wrote: > Naoya Horiguchi <n-horiguchi@...jp.nec.com> writes: > > > Basically it is user's responsibility to take care of race condition > > related to direct I/O, but some events which are out of user's control > > (such as memory failure) can happen at any time. So we need to lock and > > set/clear PG_writeback flags in dierct I/O code to protect from data loss. > > Did you do any performance testing of this? If not, please do and > report back. I'm betting users won't be pleased with the results. Here is the result of my direct I/O benchmarck, which mesures the time it takes to do direct I/O for 20000 pages on 2MB buffer for four types of I/O. Each I/O is issued for one page unit and each number below is the average of 25 runs. with patchset 2.6.35-rc3 Buffer I/O type average(s) STD(s) average(s) STD(s) diff(s) hugepage Sequential Read 3.87 0.16 3.88 0.20 -0.01 Sequential Write 7.69 0.43 7.69 0.43 0.00 Random Read 5.93 1.58 6.49 1.45 -0.55 Random Write 13.50 0.28 13.41 0.30 0.09 anonymous Sequential Read 3.88 0.21 3.89 0.23 -0.01 Sequential Write 7.86 0.39 7.80 0.34 0.05 Random Read 7.67 1.60 6.86 1.27 0.80 Random Write 13.50 0.25 13.52 0.31 -0.01 >From this result, although fluctuation is relatively large for random read, differences between vanilla kernel and patched one are within the deviations and it seems that adding direct I/O lock makes little or no impact on performance. And I know the workload of this benchmark can be too simple, so please let me know if you think we have another workload to be looked into. Thanks, Naoya Horiguchi -- 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