On Wed 17-10-18 10:29:22, Jens Axboe wrote: > 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... I know you've been advocating the use of udev for IO scheduler selection. But do you want to force everybody to use udev? And for people who build their own (usually small) systems, do you want to force them to think about IO scheduler selection and writing appropriate rules? These are the problems people were mentioning and I'm not sure what is your opinion on this. Honza -- Jan Kara <jack@xxxxxxxx> SUSE Labs, CR
