| Message ID | 20190408143935.9062-2-paolo.valente@linaro.org |
|---|---|
| State | Superseded |
| Headers | show |
| Series | bfq: remove prefixes from cgroup filenames | expand |
On Mon, Apr 08, 2019 at 04:39:35PM +0200, Paolo Valente wrote: > From: Angelo Ruocco <angeloruocco90@gmail.com> > > 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? -- Johannes Thumshirn SUSE Labs Filesystems jthumshirn@suse.de +49 911 74053 689 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
> Il giorno 8 apr 2019, alle ore 16:49, Johannes Thumshirn <jthumshirn@suse.de> ha scritto: > > On Mon, Apr 08, 2019 at 04:39:35PM +0200, Paolo Valente wrote: >> From: Angelo Ruocco <angeloruocco90@gmail.com> >> >> 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 > jthumshirn@suse.de +49 911 74053 689 > 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
On 4/8/19 8:54 AM, Paolo Valente wrote: > > >> Il giorno 8 apr 2019, alle ore 16:49, Johannes Thumshirn <jthumshirn@suse.de> ha scritto: >> >> On Mon, Apr 08, 2019 at 04:39:35PM +0200, Paolo Valente wrote: >>> From: Angelo Ruocco <angeloruocco90@gmail.com> >>> >>> 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. -- Jens Axboe
[+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@suse.de> ha scritto: > > > > On Mon, Apr 08, 2019 at 04:39:35PM +0200, Paolo Valente wrote: > >> From: Angelo Ruocco <angeloruocco90@gmail.com> > >> > >> 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 -- Johannes Thumshirn SUSE Labs Filesystems jthumshirn@suse.de +49 911 74053 689 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
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@suse.de> ha scritto: >>> >>> On Mon, Apr 08, 2019 at 04:39:35PM +0200, Paolo Valente wrote: >>>> From: Angelo Ruocco <angeloruocco90@gmail.com> >>>> >>>> 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 Axboe
> Il giorno 8 apr 2019, alle ore 17:05, Jens Axboe <axboe@kernel.dk> 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@suse.de> ha scritto: >>>> >>>> On Mon, Apr 08, 2019 at 04:39:35PM +0200, Paolo Valente wrote: >>>>> From: Angelo Ruocco <angeloruocco90@gmail.com> >>>>> >>>>> 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
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 -- Johannes Thumshirn SUSE Labs Filesystems jthumshirn@suse.de +49 911 74053 689 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
On 4/8/19 9:06 AM, Paolo Valente wrote: > > >> Il giorno 8 apr 2019, alle ore 17:05, Jens Axboe <axboe@kernel.dk> 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@suse.de> ha scritto: >>>>> >>>>> On Mon, Apr 08, 2019 at 04:39:35PM +0200, Paolo Valente wrote: >>>>>> From: Angelo Ruocco <angeloruocco90@gmail.com> >>>>>> >>>>>> 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
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. -- Jens Axboe
> Il giorno 8 apr 2019, alle ore 17:08, Johannes Thumshirn <jthumshirn@suse.de> 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 > jthumshirn@suse.de +49 911 74053 689 > 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
> Il giorno 8 apr 2019, alle ore 17:11, Jens Axboe <axboe@kernel.dk> ha scritto: > > On 4/8/19 9:06 AM, Paolo Valente wrote: >> >> >>> Il giorno 8 apr 2019, alle ore 17:05, Jens Axboe <axboe@kernel.dk> 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@suse.de> ha scritto: >>>>>> >>>>>> On Mon, Apr 08, 2019 at 04:39:35PM +0200, Paolo Valente wrote: >>>>>>> From: Angelo Ruocco <angeloruocco90@gmail.com> >>>>>>> >>>>>>> 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
On 4/8/19 9:14 AM, Paolo Valente wrote: > > >> Il giorno 8 apr 2019, alle ore 17:08, Johannes Thumshirn <jthumshirn@suse.de> 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. -- Jens Axboe
> Il giorno 8 apr 2019, alle ore 17:13, Jens Axboe <axboe@kernel.dk> 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 >
> Il giorno 8 apr 2019, alle ore 17:17, Jens Axboe <axboe@kernel.dk> ha scritto: > > On 4/8/19 9:14 AM, Paolo Valente wrote: >> >> >>> Il giorno 8 apr 2019, alle ore 17:08, Johannes Thumshirn <jthumshirn@suse.de> 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
On Mon, 8 Apr 2019 at 17:05, Jens Axboe <axboe@kernel.dk> 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 <jthumshirn@suse.de> ha scritto: > >>> > >>> On Mon, Apr 08, 2019 at 04:39:35PM +0200, Paolo Valente wrote: > >>>> From: Angelo Ruocco <angeloruocco90@gmail.com> > >>>> > >>>> 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
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,