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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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




[Index of Archives]     [Linux RAID]     [Linux SCSI]     [Linux ATA RAID]     [IDE]     [Linux Wireless]     [Linux Kernel]     [ATH6KL]     [Linux Bluetooth]     [Linux Netdev]     [Kernel Newbies]     [Security]     [Git]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Device Mapper]

  Powered by Linux