On 10/17/18 4:05 AM, Jan Kara wrote: > 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... Which is also the approach that I've been advocating for here, instead of a kernel patch... -- Jens Axboe
