Hi Jens,
now that BFQ's weight interface has been fixed [1], can we proceed
with this change?
In addition to acking this solution, in [2] Tejun already suggested a
reduced version of the present patch. In Tejun's version, only
bfq.weight is changed. But I guess that legacy code may use also some
of the other bfq parameters in cgroups, without the bfq prefix. Apart
from that, any version is ok for me, provided that it solves the
current confusing situation for userspace [3].
Thanks,
Paolo
[1] https://lkml.org/lkml/2019/8/27/1716
[2] https://www.mail-archive.com/[email protected]/msg35823.html
[3] https://github.com/systemd/systemd/issues/7057
Angelo Ruocco (1):
block, bfq: delete "bfq" prefix from cgroup filenames
block/bfq-cgroup.c | 46 +++++++++++++++++++++++-----------------------
1 file changed, 23 insertions(+), 23 deletions(-)
--
2.20.1
From: Angelo Ruocco <[email protected]>
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 <[email protected]>
Signed-off-by: Paolo Valente <[email protected]>
---
block/bfq-cgroup.c | 46 +++++++++++++++++++++++-----------------------
1 file changed, 23 insertions(+), 23 deletions(-)
diff --git a/block/bfq-cgroup.c b/block/bfq-cgroup.c
index 0f6cd688924f..14b7a1160664 100644
--- a/block/bfq-cgroup.c
+++ b/block/bfq-cgroup.c
@@ -1139,7 +1139,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,
@@ -1147,42 +1147,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_BFQ_CGROUP_DEBUG
{
- .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,
},
@@ -1190,66 +1190,66 @@ struct cftype bfq_blkcg_legacy_files[] = {
/* the same statistics 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_BFQ_CGROUP_DEBUG
{
- .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,
},
@@ -1259,7 +1259,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,
--
2.20.1
> Il giorno 16 set 2019, alle ore 17:01, Jens Axboe <[email protected]> ha scritto:
>
> On 9/16/19 8:56 AM, Paolo Valente wrote:
>> News of this change? Can we have it (or the solution with the
>> symlinks if you prefer it) for 5.4?
>
> Coordinate with Tejun and bundle the stuff we need into a series,
Ok.
Tejun, could you put your switch-off-io-cost code into a standalone
patch, so that I can put it together with this one in a complete
series?
Thanks,
Paolo
> we
> can definitely put that in 5.4. I did send out the initial pull request
> for block, but I've got a few things lined up for a secondary pull
> later this week.
>
> --
> Jens Axboe
>
News of this change? Can we have it (or the solution with the
symlinks if you prefer it) for 5.4?
Thanks,
Paolo
> Il giorno 9 set 2019, alle ore 09:31, Paolo Valente <[email protected]> ha scritto:
>
> Hi Jens,
> now that BFQ's weight interface has been fixed [1], can we proceed
> with this change?
>
> In addition to acking this solution, in [2] Tejun already suggested a
> reduced version of the present patch. In Tejun's version, only
> bfq.weight is changed. But I guess that legacy code may use also some
> of the other bfq parameters in cgroups, without the bfq prefix. Apart
> from that, any version is ok for me, provided that it solves the
> current confusing situation for userspace [3].
>
> Thanks,
> Paolo
>
> [1] https://lkml.org/lkml/2019/8/27/1716
> [2] https://www.mail-archive.com/[email protected]/msg35823.html
> [3] https://github.com/systemd/systemd/issues/7057
>
> Angelo Ruocco (1):
> block, bfq: delete "bfq" prefix from cgroup filenames
>
> block/bfq-cgroup.c | 46 +++++++++++++++++++++++-----------------------
> 1 file changed, 23 insertions(+), 23 deletions(-)
>
> --
> 2.20.1
On 9/16/19 8:56 AM, Paolo Valente wrote:
> News of this change? Can we have it (or the solution with the
> symlinks if you prefer it) for 5.4?
Coordinate with Tejun and bundle the stuff we need into a series, we
can definitely put that in 5.4. I did send out the initial pull request
for block, but I've got a few things lined up for a secondary pull
later this week.
--
Jens Axboe
Hello, Paolo.
On Mon, Sep 16, 2019 at 05:07:29PM +0200, Paolo Valente wrote:
> Tejun, could you put your switch-off-io-cost code into a standalone
> patch, so that I can put it together with this one in a complete
> series?
It was more of a proof-of-concept / example, so the note in the email
that the code is free to be modified / used any way you see fit. That
said, if you like it as it is, I can surely prep it as a standalone
patch.
Thanks.
--
tejun
> Il giorno 16 set 2019, alle ore 17:16, Tejun Heo <[email protected]> ha scritto:
>
> Hello, Paolo.
>
> On Mon, Sep 16, 2019 at 05:07:29PM +0200, Paolo Valente wrote:
>> Tejun, could you put your switch-off-io-cost code into a standalone
>> patch, so that I can put it together with this one in a complete
>> series?
>
> It was more of a proof-of-concept / example, so the note in the email
> that the code is free to be modified / used any way you see fit. That
> said, if you like it as it is, I can surely prep it as a standalone
> patch.
>
AFAICT your proposal contains no evident error. Plus, no one seems to
have complained about the idea (regardless from the exact
implementation). So I guess the best next step is to go for it.
Thanks,
Paolo
> Thanks.
>
> --
> tejun
On 9/16/19 9:21 AM, Paolo Valente wrote:
>
>
>> Il giorno 16 set 2019, alle ore 17:16, Tejun Heo <[email protected]> ha scritto:
>>
>> Hello, Paolo.
>>
>> On Mon, Sep 16, 2019 at 05:07:29PM +0200, Paolo Valente wrote:
>>> Tejun, could you put your switch-off-io-cost code into a standalone
>>> patch, so that I can put it together with this one in a complete
>>> series?
>>
>> It was more of a proof-of-concept / example, so the note in the email
>> that the code is free to be modified / used any way you see fit. That
>> said, if you like it as it is, I can surely prep it as a standalone
>> patch.
>>
>
> AFAICT your proposal contains no evident error. Plus, no one seems to
> have complained about the idea (regardless from the exact
> implementation). So I guess the best next step is to go for it.
Not filling me with a lot of confidence that you actually tested it?
--
Jens Axboe
> Il giorno 16 set 2019, alle ore 18:01, Jens Axboe <[email protected]> ha scritto:
>
> On 9/16/19 9:21 AM, Paolo Valente wrote:
>>
>>
>>> Il giorno 16 set 2019, alle ore 17:16, Tejun Heo <[email protected]> ha scritto:
>>>
>>> Hello, Paolo.
>>>
>>> On Mon, Sep 16, 2019 at 05:07:29PM +0200, Paolo Valente wrote:
>>>> Tejun, could you put your switch-off-io-cost code into a standalone
>>>> patch, so that I can put it together with this one in a complete
>>>> series?
>>>
>>> It was more of a proof-of-concept / example, so the note in the email
>>> that the code is free to be modified / used any way you see fit. That
>>> said, if you like it as it is, I can surely prep it as a standalone
>>> patch.
>>>
>>
>> AFAICT your proposal contains no evident error. Plus, no one seems to
>> have complained about the idea (regardless from the exact
>> implementation). So I guess the best next step is to go for it.
>
> Not filling me with a lot of confidence that you actually tested it?
>
Tested it too. Waiting for Tejun's patch to re-submit it with mine.
Thanks,
Paolo
> --
> Jens Axboe
On Mon, Sep 16, 2019 at 06:45:03PM +0200, Paolo Valente wrote:
> Tested it too. Waiting for Tejun's patch to re-submit it with mine.
http://lkml.kernel.org/r/[email protected]
Thanks.
--
tejun