On Tue 16-10-18 11:35:59, Jens Axboe wrote: > On 10/15/18 1:44 PM, Paolo Valente wrote: > > Here are some old results with a very simple configuration: > > http://algo.ing.unimo.it/people/paolo/disk_sched/old-results/4.4.0-v7r11/ > > http://algo.ing.unimo.it/people/paolo/disk_sched/old-results/3.14.0-v7r3/ > > http://algo.ing.unimo.it/people/paolo/disk_sched/old-results/3.13.0-v7r2/ > > > > Then I stopped repeating tests that always yielded the same good results. > > > > As for more professional systems, a well-known company doing > > real-time packet-traffic dumping asked me to modify bfq so as to > > guarantee lossless data writing also during queries. The involved box > > had a RAID reaching a few Gbps, and everything worked well. > > > > Anyway, if you have specific issues in mind, I can check more deeply. > > Do you have anything more recent? All of these predate the current > code (by a lot), and isn't even mq. I'm mostly just interested in > plain fast NVMe device, and a big box hardware raid setup with > a ton of drives. > > I do still think that this should be going through the distros, they > need to be the ones driving this, as they will ultimately be the > ones getting customer reports on regressions. The qual/test cycle > they do is useful for this. In mainline, if we make a change like > this, we'll figure out if it worked many releases down the line. Well, the problem with this is that big distro people really don't care much because they already use udev for tuning the IO scheduler. So whatever defaults the kernel is going to pick likely won't be seen by distro customers. Embedded people seem to be driving this effort because they either don't run udev or they feel not all their teams building new products have enough expertise to come up with a proper set of rules... Honza -- Jan Kara <jack@xxxxxxxx> SUSE Labs, CR
