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: Fri, 9 Oct 2009 16:34:08 -0700 From: Jiaying Zhang <jiayingz@...gle.com> To: ext4 development <linux-ext4@...r.kernel.org> Cc: Andrew Morton <akpm@...gle.com>, Michael Rubin <mrubin@...gle.com>, Manuel Benitez <rickyb@...gle.com> Subject: ext4 DIO read performance issue on SSD Hello, Recently, we are evaluating the ext4 performance on a high speed SSD. One problem we found is that ext4 performance doesn't scale well with multiple threads or multiple AIOs reading a single file with O_DIRECT. E.g., with 4k block size, multiple-thread DIO AIO random read on ext4 can lose up to 50% throughput compared to the results we get via RAW IO. After some initial analysis, we think the ext4 performance problem is caused by the use of i_mutex lock during DIO read. I.e., during DIO read, we grab the i_mutex lock in __blockdev_direct_IO because ext4 uses the default DIO_LOCKING from the generic fs code. I did a quick test by calling blockdev_direct_IO_no_locking() in ext4_direct_IO() and I saw ext4 DIO read got 99% performance as raw IO. As we understand, the reason why we want to take i_mutex lock during DIO read is to prevent it from accessing stale data that may be exposed by a simultaneous write. We saw that Mingming Cao has implemented a patch set with which when a get_block request comes from direct write, ext4 only allocates or splits an uninitialized extent. That uninitialized extent will be marked as initialized at the end_io callback. We are wondering whether we can extend this idea to buffer write as well. I.e., we always allocate an uninitialized extent first during any write and convert it as initialized at the time of end_io callback. This will eliminate the need to hold i_mutex lock during direct read because a DIO read should never get a block marked initialized before the block has been written with new data. We haven't implemented anything yet because we want to ask here first to see whether this proposal makes sense to you. Regards, Jiaying -- To unsubscribe from this list: send the line "unsubscribe linux-ext4" in the body of a message to majordomo@...r.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists