Re: [PATCH 1/1] block, bfq: delete "bfq" prefix from cgroup filenames

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

 



On 4/8/19 9:06 AM, Paolo Valente wrote:
> 
> 
>> Il giorno 8 apr 2019, alle ore 17:05, Jens Axboe <axboe@xxxxxxxxx> ha scritto:
>>
>> On 4/8/19 9:04 AM, Johannes Thumshirn wrote:
>>> [+Cc Michal ]
>>> On Mon, Apr 08, 2019 at 04:54:39PM +0200, Paolo Valente wrote:
>>>>
>>>>
>>>>> Il giorno 8 apr 2019, alle ore 16:49, Johannes Thumshirn <jthumshirn@xxxxxxx> ha scritto:
>>>>>
>>>>> On Mon, Apr 08, 2019 at 04:39:35PM +0200, Paolo Valente wrote:
>>>>>> From: Angelo Ruocco <angeloruocco90@xxxxxxxxx>
>>>>>>
>>>>>> When bfq was merged into mainline, there were two I/O schedulers that
>>>>>> implemented the proportional-share policy: bfq for blk-mq and cfq for
>>>>>> legacy blk. bfq's interface files in the blkio/io controller have the
>>>>>> same names as cfq. But the cgroups interface doesn't allow two
>>>>>> entities to use the same name for their files, so for bfq we had to
>>>>>> prepend the "bfq" prefix to each of its files. However no legacy code
>>>>>> uses these modified file names. This naming also causes confusion, as,
>>>>>> e.g., in [1].
>>>>>>
>>>>>> Now cfq has gone with legacy blk, so there is no need any longer for
>>>>>> these prefixes in (the never used) bfq names. In view of this fact, this
>>>>>> commit removes these prefixes, thereby enabling legacy code to truly
>>>>>> use the proportional share policy in blk-mq.
>>>>>>
>>>>>> [1] https://github.com/systemd/systemd/issues/7057
>>>>>
>>>>> Hmm, but isn't this a user-space facing interface and thus some sort of ABI?
>>>>> Do you know what's using it and what breaks due to this conversion?
>>>>>
>>>>
>>>> Yep, but AFAIK, the problem is exactly the opposite: nobody uses these
>>>> names for the proportional-share policy, or wants to use these names.  I'm
>>>> CCing Lennart too, in case he has some improbable news on this.
>>>>
>>>> So the idea is to align names to what people expect, possibly before
>>>> more confusion arises.
>>>
>>> OK, crazy idea, not sure if Jens and Tejun will beat me for this, but
>>> symlinks?
>>>
>>> This way we can a) keep the old files and b) have them point to the new (a.k.a
>>> cfq style) files.
>>
>> I did consider that, and that would be doable. But honestly, I'm having a
>> hard time seeing what issue we are attempting to fix by doing this.
>>
> 
> The problem is ~100% of people and software believing to set weights and not doing it.

I'm sorry, but I don't know what that means?

-- 
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