| 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
| ||
|
Message-Id: <1158276972.24991.10.camel@dyn9047017100.beaverton.ibm.com> Date: Thu, 14 Sep 2006 16:36:12 -0700 From: Badari Pulavarty <pbadari@...ibm.com> To: akpm@...l.org, sct@...hat.com Cc: ext4 <linux-ext4@...r.kernel.org> Subject: ext3 sequential read performance (~20%) degrade Hi Andrew, I have been working on tracking down ~20% performance degrade for sequential read performance for ext3. Finally narrowed it down to get_blocks() support. If I force ext3_get_blocks_handle() to always return 1 block - I get better IO rate. I did all the usual stuff, tracked down requests, traced blocksizes, looked at readahead code, looked at mpage_readpages() etc.. I still can't figure out how to explain the degrade.. Any suggestions on how to track it down. Thanks, Badari # cat iotest mount /dev/sdb2 /mnt/tmp time dd if=/mnt/tmp/testfile of=/dev/null bs=4k count=1048576 umount /mnt/tmp 2.6.18-rc6: (multiblock): # ./iotest 1048576+0 records in 1048576+0 records out 4294967296 bytes (4.3 GB) copied, 75.2654 seconds, 57.1 MB/s real 1m15.282s user 0m0.248s sys 0m4.292s 2.6.18-rc6 (force single block in ext3_get_blocks_handle(): # ./iotest ./iotest 1048576+0 records in 1048576+0 records out 4294967296 bytes (4.3 GB) copied, 62.9472 seconds, 68.2 MB/s real 1m2.976s user 0m0.268s sys 0m4.280s - 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