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

Commit Message

Paolo Valente April 8, 2019, 2:39 p.m. UTC

From: Angelo Ruocco <[e-mail]>

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

Signed-off-by: Angelo Ruocco <[e-mail]>
Signed-off-by: Paolo Valente <[e-mail]>
---
 block/bfq-cgroup.c | 46 +++++++++++++++++++++++-----------------------
 1 file changed, 23 insertions(+), 23 deletions(-)

Comments

Johannes Thumshirn April 8, 2019, 2:49 p.m. UTC | #1

On Mon, Apr 08, 2019 at 04:39:35PM +0200, Paolo Valente wrote:
> From: Angelo Ruocco <[e-mail]>
> 
> 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?

Paolo Valente April 8, 2019, 2:54 p.m. UTC | #2

> Il giorno 8 apr 2019, alle ore 16:49, Johannes Thumshirn <[e-mail]> ha scritto:
> 
> On Mon, Apr 08, 2019 at 04:39:35PM +0200, Paolo Valente wrote:
>> From: Angelo Ruocco <[e-mail]>
>> 
>> 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.

Thanks,
Paolo

> -- 
> Johannes Thumshirn                            SUSE Labs Filesystems
> [e-mail]                                [phone]
> SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg
> GF: Felix Imendörffer, Mary Higgins, Sri Rasiah
> HRB 21284 (AG Nürnberg)
> Key fingerprint = EC38 9CAB C2C4 F25D 8600 D0D0 0393 969D 2D76 0850

Jens Axboe April 8, 2019, 3:01 p.m. UTC | #3

On 4/8/19 8:54 AM, Paolo Valente wrote:
> 
> 
>> Il giorno 8 apr 2019, alle ore 16:49, Johannes Thumshirn <[e-mail]> ha scritto:
>>
>> On Mon, Apr 08, 2019 at 04:39:35PM +0200, Paolo Valente wrote:
>>> From: Angelo Ruocco <[e-mail]>
>>>
>>> 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.

We can't just rename them since they've already been in a shipped kernel.
The window for doing this passed long ago.

Johannes Thumshirn April 8, 2019, 3:04 p.m. UTC | #4

[+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 <[e-mail]> ha scritto:
> > 
> > On Mon, Apr 08, 2019 at 04:39:35PM +0200, Paolo Valente wrote:
> >> From: Angelo Ruocco <[e-mail]>
> >> 
> >> 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.

Byte,
	Johannes

Jens Axboe April 8, 2019, 3:05 p.m. UTC | #5

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 <[e-mail]> ha scritto:
>>>
>>> On Mon, Apr 08, 2019 at 04:39:35PM +0200, Paolo Valente wrote:
>>>> From: Angelo Ruocco <[e-mail]>
>>>>
>>>> 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.

Paolo Valente April 8, 2019, 3:06 p.m. UTC | #6

> Il giorno 8 apr 2019, alle ore 17:05, Jens Axboe <[e-mail]> 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 <[e-mail]> ha scritto:
>>>> 
>>>> On Mon, Apr 08, 2019 at 04:39:35PM +0200, Paolo Valente wrote:
>>>>> From: Angelo Ruocco <[e-mail]>
>>>>> 
>>>>> 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.

Paolo

> -- 
> Jens Axboe

Johannes Thumshirn April 8, 2019, 3:08 p.m. UTC | #7

On Mon, Apr 08, 2019 at 09:05:19AM -0600, Jens Axboe wrote:
> 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.

Yeah, I guess the real fix would be to update the documentation and the
expectations user-space has. Including eventual re-write of some udev rules or
whatever is facing these files. But to me that sounds more like a systemd or
even distro thing than a kernel thing.

Byte,
	Johannes

Jens Axboe April 8, 2019, 3:11 p.m. UTC | #8

On 4/8/19 9:06 AM, Paolo Valente wrote:
> 
> 
>> Il giorno 8 apr 2019, alle ore 17:05, Jens Axboe <[e-mail]> 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 <[e-mail]> ha scritto:
>>>>>
>>>>> On Mon, Apr 08, 2019 at 04:39:35PM +0200, Paolo Valente wrote:
>>>>>> From: Angelo Ruocco <[e-mail]>
>>>>>>
>>>>>> 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 April 8, 2019, 3:13 p.m. UTC | #9

On 4/8/19 9:08 AM, Johannes Thumshirn wrote:
> On Mon, Apr 08, 2019 at 09:05:19AM -0600, Jens Axboe wrote:
>> 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.
> 
> Yeah, I guess the real fix would be to update the documentation and the
> expectations user-space has. Including eventual re-write of some udev rules or
> whatever is facing these files. But to me that sounds more like a systemd or
> even distro thing than a kernel thing.

I agree. Trying to force someones hand by renaming isn't going to fix
anything, but it will potentially cause issues.

Paolo Valente April 8, 2019, 3:14 p.m. UTC | #10

> Il giorno 8 apr 2019, alle ore 17:08, Johannes Thumshirn <[e-mail]> ha scritto:
> 
> On Mon, Apr 08, 2019 at 09:05:19AM -0600, Jens Axboe wrote:
>> 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.
> 
> Yeah, I guess the real fix would be to update the documentation and the
> expectations user-space has. Including eventual re-write of some udev rules or
> whatever is facing these files. But to me that sounds more like a systemd or
> even distro thing than a kernel thing.
> 

Unfortunately the user-space people I have interacted with find crazy
to have to change their software to call bfq.weight the weight of a
group.  And are not willing to do it [1].

Thanks,
Paolo

[1] https://github.com/systemd/systemd/issues/7057

> Byte,
> 	Johannes
> -- 
> Johannes Thumshirn                            SUSE Labs Filesystems
> [e-mail]                                [phone]
> SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg
> GF: Felix Imendörffer, Mary Higgins, Sri Rasiah
> HRB 21284 (AG Nürnberg)
> Key fingerprint = EC38 9CAB C2C4 F25D 8600 D0D0 0393 969D 2D76 0850

Paolo Valente April 8, 2019, 3:15 p.m. UTC | #11

> Il giorno 8 apr 2019, alle ore 17:11, Jens Axboe <[e-mail]> ha scritto:
> 
> On 4/8/19 9:06 AM, Paolo Valente wrote:
>> 
>> 
>>> Il giorno 8 apr 2019, alle ore 17:05, Jens Axboe <[e-mail]> 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 <[e-mail]> ha scritto:
>>>>>> 
>>>>>> On Mon, Apr 08, 2019 at 04:39:35PM +0200, Paolo Valente wrote:
>>>>>>> From: Angelo Ruocco <[e-mail]>
>>>>>>> 
>>>>>>> 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?
> 

It means that people and code set weights, not bfq.weights.

Thanks,
Paolo

> -- 
> Jens Axboe

Jens Axboe April 8, 2019, 3:17 p.m. UTC | #12

On 4/8/19 9:14 AM, Paolo Valente wrote:
> 
> 
>> Il giorno 8 apr 2019, alle ore 17:08, Johannes Thumshirn <[e-mail]> ha scritto:
>>
>> On Mon, Apr 08, 2019 at 09:05:19AM -0600, Jens Axboe wrote:
>>> 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.
>>
>> Yeah, I guess the real fix would be to update the documentation and the
>> expectations user-space has. Including eventual re-write of some udev rules or
>> whatever is facing these files. But to me that sounds more like a systemd or
>> even distro thing than a kernel thing.
>>
> 
> Unfortunately the user-space people I have interacted with find crazy
> to have to change their software to call bfq.weight the weight of a
> group.  And are not willing to do it [1].

Then you need to educate them. Some of the issues were called out years
ago, at the time when we could have potentially renamed. A rename now
will solve nothing.

Paolo Valente April 8, 2019, 3:19 p.m. UTC | #13

> Il giorno 8 apr 2019, alle ore 17:13, Jens Axboe <[e-mail]> ha scritto:
> 
> On 4/8/19 9:08 AM, Johannes Thumshirn wrote:
>> On Mon, Apr 08, 2019 at 09:05:19AM -0600, Jens Axboe wrote:
>>> 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.
>> 
>> Yeah, I guess the real fix would be to update the documentation and the
>> expectations user-space has. Including eventual re-write of some udev rules or
>> whatever is facing these files. But to me that sounds more like a systemd or
>> even distro thing than a kernel thing.
> 
> I agree. Trying to force someones hand by renaming isn't going to fix
> anything, but it will potentially cause issues.
> 

Potential issues against concrete, big issues already with us.  The
proportional share interface doesn't match the idea people have of it.

I don't want to push for this solution, but we cannot pretend we don't
have a big problem already.  Any solution that could really work is ok
for me, including symlinks.

Thanks,
Paolo

> -- 
> Jens Axboe
>

Paolo Valente April 8, 2019, 5:01 p.m. UTC | #14

> Il giorno 8 apr 2019, alle ore 17:17, Jens Axboe <[e-mail]> ha scritto:
> 
> On 4/8/19 9:14 AM, Paolo Valente wrote:
>> 
>> 
>>> Il giorno 8 apr 2019, alle ore 17:08, Johannes Thumshirn <[e-mail]> ha scritto:
>>> 
>>> On Mon, Apr 08, 2019 at 09:05:19AM -0600, Jens Axboe wrote:
>>>> 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.
>>> 
>>> Yeah, I guess the real fix would be to update the documentation and the
>>> expectations user-space has. Including eventual re-write of some udev rules or
>>> whatever is facing these files. But to me that sounds more like a systemd or
>>> even distro thing than a kernel thing.
>>> 
>> 
>> Unfortunately the user-space people I have interacted with find crazy
>> to have to change their software to call bfq.weight the weight of a
>> group.  And are not willing to do it [1].
> 
> Then you need to educate them.

I'm not sure that educate is the right verb (I don't like the current
messy solution either).  But I'll do my best to inform people when
I'll have the opportunity to do it.

> Some of the issues were called out years
> ago, at the time when we could have potentially renamed.

Yeah, a good window was 5.0, and at that time we tried with a more
general solution.  But we failed.


> A rename now
> will solve nothing.
> 

I see your point, but I don't agree this rename would solve nothing.
The real bad thing is not having done this before.  Changing names
that nobody uses, to names that everybody already uses, but wrongly,
would instantaneously improve the situation a lot.  And it is what
userspace already asked explicitly for [1].  Without this simple
change, it will take a lot for all the inconsistent documentation
spread around the world to be synced.  And for all legacy software to
be changed, assuming it will all be changed.

Paolo

[1] https://github.com/systemd/systemd/issues/7057

> -- 
> Jens Axboe

Ulf Hansson April 10, 2019, 11:42 a.m. UTC | #15

On Mon, 8 Apr 2019 at 17:05, Jens Axboe <[e-mail]> wrote:
>
> 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 <[e-mail]> ha scritto:
> >>>
> >>> On Mon, Apr 08, 2019 at 04:39:35PM +0200, Paolo Valente wrote:
> >>>> From: Angelo Ruocco <[e-mail]>
> >>>>
> >>>> 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.

Jens, didn't we actually break userspace ABI when dropping the legacy
block code and its I/O schedulers?

So, to me, it seems like introducing symlinks as suggested above,
would actually fix this "regression", wouldn't it?

Kind regards
Uffe

Patch

diff --git a/block/bfq-cgroup.c b/block/bfq-cgroup.c
index c6113af31960..319c2444dc71 100644
--- a/block/bfq-cgroup.c
+++ b/block/bfq-cgroup.c
@@ -1053,7 +1053,7 @@  struct blkcg_policy blkcg_policy_bfq = {
 
 struct cftype bfq_blkcg_legacy_files[] = {
 	{
-		.name = "bfq.weight",
+		.name = "weight",
 		.flags = CFTYPE_NOT_ON_ROOT,
 		.seq_show = bfq_io_show_weight,
 		.write_u64 = bfq_io_set_weight_legacy,
@@ -1061,42 +1061,42 @@  struct cftype bfq_blkcg_legacy_files[] = {
 
 	/* statistics, covers only the tasks in the bfqg */
 	{
-		.name = "bfq.io_service_bytes",
+		.name = "io_service_bytes",
 		.private = (unsigned long)&blkcg_policy_bfq,
 		.seq_show = blkg_print_stat_bytes,
 	},
 	{
-		.name = "bfq.io_serviced",
+		.name = "io_serviced",
 		.private = (unsigned long)&blkcg_policy_bfq,
 		.seq_show = blkg_print_stat_ios,
 	},
 #ifdef CONFIG_DEBUG_BLK_CGROUP
 	{
-		.name = "bfq.time",
+		.name = "time",
 		.private = offsetof(struct bfq_group, stats.time),
 		.seq_show = bfqg_print_stat,
 	},
 	{
-		.name = "bfq.sectors",
+		.name = "sectors",
 		.seq_show = bfqg_print_stat_sectors,
 	},
 	{
-		.name = "bfq.io_service_time",
+		.name = "io_service_time",
 		.private = offsetof(struct bfq_group, stats.service_time),
 		.seq_show = bfqg_print_rwstat,
 	},
 	{
-		.name = "bfq.io_wait_time",
+		.name = "io_wait_time",
 		.private = offsetof(struct bfq_group, stats.wait_time),
 		.seq_show = bfqg_print_rwstat,
 	},
 	{
-		.name = "bfq.io_merged",
+		.name = "io_merged",
 		.private = offsetof(struct bfq_group, stats.merged),
 		.seq_show = bfqg_print_rwstat,
 	},
 	{
-		.name = "bfq.io_queued",
+		.name = "io_queued",
 		.private = offsetof(struct bfq_group, stats.queued),
 		.seq_show = bfqg_print_rwstat,
 	},
@@ -1104,66 +1104,66 @@  struct cftype bfq_blkcg_legacy_files[] = {
 
 	/* the same statictics which cover the bfqg and its descendants */
 	{
-		.name = "bfq.io_service_bytes_recursive",
+		.name = "io_service_bytes_recursive",
 		.private = (unsigned long)&blkcg_policy_bfq,
 		.seq_show = blkg_print_stat_bytes_recursive,
 	},
 	{
-		.name = "bfq.io_serviced_recursive",
+		.name = "io_serviced_recursive",
 		.private = (unsigned long)&blkcg_policy_bfq,
 		.seq_show = blkg_print_stat_ios_recursive,
 	},
 #ifdef CONFIG_DEBUG_BLK_CGROUP
 	{
-		.name = "bfq.time_recursive",
+		.name = "time_recursive",
 		.private = offsetof(struct bfq_group, stats.time),
 		.seq_show = bfqg_print_stat_recursive,
 	},
 	{
-		.name = "bfq.sectors_recursive",
+		.name = "sectors_recursive",
 		.seq_show = bfqg_print_stat_sectors_recursive,
 	},
 	{
-		.name = "bfq.io_service_time_recursive",
+		.name = "io_service_time_recursive",
 		.private = offsetof(struct bfq_group, stats.service_time),
 		.seq_show = bfqg_print_rwstat_recursive,
 	},
 	{
-		.name = "bfq.io_wait_time_recursive",
+		.name = "io_wait_time_recursive",
 		.private = offsetof(struct bfq_group, stats.wait_time),
 		.seq_show = bfqg_print_rwstat_recursive,
 	},
 	{
-		.name = "bfq.io_merged_recursive",
+		.name = "io_merged_recursive",
 		.private = offsetof(struct bfq_group, stats.merged),
 		.seq_show = bfqg_print_rwstat_recursive,
 	},
 	{
-		.name = "bfq.io_queued_recursive",
+		.name = "io_queued_recursive",
 		.private = offsetof(struct bfq_group, stats.queued),
 		.seq_show = bfqg_print_rwstat_recursive,
 	},
 	{
-		.name = "bfq.avg_queue_size",
+		.name = "avg_queue_size",
 		.seq_show = bfqg_print_avg_queue_size,
 	},
 	{
-		.name = "bfq.group_wait_time",
+		.name = "group_wait_time",
 		.private = offsetof(struct bfq_group, stats.group_wait_time),
 		.seq_show = bfqg_print_stat,
 	},
 	{
-		.name = "bfq.idle_time",
+		.name = "idle_time",
 		.private = offsetof(struct bfq_group, stats.idle_time),
 		.seq_show = bfqg_print_stat,
 	},
 	{
-		.name = "bfq.empty_time",
+		.name = "empty_time",
 		.private = offsetof(struct bfq_group, stats.empty_time),
 		.seq_show = bfqg_print_stat,
 	},
 	{
-		.name = "bfq.dequeue",
+		.name = "dequeue",
 		.private = offsetof(struct bfq_group, stats.dequeue),
 		.seq_show = bfqg_print_stat,
 	},
@@ -1173,7 +1173,7 @@  struct cftype bfq_blkcg_legacy_files[] = {
 
 struct cftype bfq_blkg_files[] = {
 	{
-		.name = "bfq.weight",
+		.name = "weight",
 		.flags = CFTYPE_NOT_ON_ROOT,
 		.seq_show = bfq_io_show_weight,
 		.write = bfq_io_set_weight,