Subject : fio sync read 4k block size 35% regression Submitter : "Zhang, Yanmin" <yanmin_zhang@linux.intel.com> Date : 2009-07-01 11:25 References : http://lkml.org/lkml/2009/6/30/679 Handled-By : Wu Fengguang <fengguang.wu@intel.com> This entry is being used for tracking a regression from 2.6.30. Please don't close it until the problem is fixed in the mainline. Caused by: commit 51daa88ebd8e0d437289f589af29d4b39379ea76 Author: Wu Fengguang <fengguang.wu@intel.com> Date: Tue Jun 16 15:31:24 2009 -0700 readahead: remove sync/async readahead call dependency First-Bad-Commit : 51daa88ebd8e0d437289f589af29d4b39379ea76
On Tuesday 07 July 2009, Zhang, Yanmin wrote: > On Tue, 2009-07-07 at 02:01 +0200, Rafael J. Wysocki wrote: > > This message has been generated automatically as a part of a report > > of recent regressions. > > > > The following bug entry is on the current list of known regressions > > from 2.6.30. Please verify if it still should be listed and let me know > > (either way). > > > > > > Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13726 > > Subject : fio sync read 4k block size 35% regression > > Submitter : Zhang, Yanmin <yanmin_zhang@linux.intel.com> > > Date : 2009-07-01 11:25 (6 days old) > > I'm still working on it now. The new testing against 2.6.31-rc2 is ongoing. > fio sync/mmap read has new behavior. I did collect some data. But suddenly > with new created data, the fio_sync_read_4k regression disappeared, while > fio_mmap_read is still there. Originally, the testing and bisect were stable. > Let me check what happens firstly.
I found something new with the workload. 1) The parameters of FIO I used cause fio to read files round-robin and every I/O only consists of a block; original, I imagine it read a complete file, then switch to another file; 2) fio is a typical disk I/O testing benchmark, so cpu utilization is very little. I found such cpu C states have big impact on such workload results, especially on Nehalem machines. On my Nehalem machine, cpu enters C2/C3 frequently which causes a long latency to restore to C0 state. It hurts fio result on Nehalem machine. I add idle=poll to kernel boot command line now. 3) FengGuang thinks round-robin is a good test scenario, so I add new sub-cases, including read sequential and read round-robin. I would like to close the report now. If finding new issues with new revised test cases, I will open new reports. Thanks, Yanmin