Re: [PATCH v2] block: BFQ default for single queue devices

[Jens Axboe <axboe@xxxxxxxxx>]

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


______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/