Sir, The HDD is hardware Raid 5 with 530-8i raid card. I tried 1m seq write with numjobs=1, the data similar as kernel 3.10.0, whatever mq-deadline or BFQ elevator. If you need detail testing data with numjobs=1, I can do it. Or any info you need, such as two process with 1 thread.
Thank you. BestRegards, SunnyLiu(刘萍) LenovoNetApp 北京市海淀区西北旺东路10号院2号楼L3-E1-01 L3-E1-01,Building No.2, Lenovo HQ West No.10 XiBeiWang East Rd., Haidian District, Beijing 100094, PRC Tel: +86 15910622368 -----Original Message----- From: [email protected] <[email protected]> On Behalf Of Damien Le Moal Sent: 2019年9月19日 20:45 To: Liu, Sunny <[email protected]>; Hannes Reinecke <[email protected]>; Jens Axboe <[email protected]> Cc: [email protected]; Martin K. Petersen <[email protected]>; James Bottomley <[email protected]>; Christoph Hellwig <[email protected]>; [email protected]; Hans Holmberg <[email protected]> Subject: Re: [RFC PATCH 0/2] blk-mq I/O scheduling fixes On 2019/09/19 12:59, Liu, Sunny wrote: > Thank very much for your quickly advice. > > The problem drive is sata HDD 7200rpm in raid 5. Sorry, I read "SDD" where you had written "HDD" :) Is this a hardware RAID ? Or is this using dm/md raid ? > If using Fio libaio iodepth=128 numjob=2, the bad performance will be > as below in red. But there is no problem with numjob=1. In our > solution, *multiple > threads* should be used. Your data does not have the numjobs=1 case for kernel 5.2.9. You should run that for comparison with the numjobs=2 case on the same kernel. > From the testing result, BFQ low-latency had good performance, but it > still has problem in 1m seq write. > > The data is come from centos 7.6 (kernel 3.10.0-975) and kernel 5.2.9 > with BFQ and bcache enabled. No bcache configure. > > Is there any parameter can solve the 1m and upper seq write problem > with multiple threads? Not sure what the problem is here. You could look at a blktrace of each case to see if there is any major difference in the command patterns sent to the disks of your array, in particular command size. -- Damien Le Moal Western Digital Research
