hmm, i wa sof the impression the kernel folks will fix this for us. i.e. by adding a symlink so that userspace doesn't has to be adjusted to any frickin elevator the kernel folks add.

@htejun what's the status quo on this, do you know?

i really hope that we don't need kludges like this in userspace in the long run, to work around differences between different elevators from userspace?

/cc @cdown

/cc @paolo-github

At least as of now, the interfaces are incompatible: io.bfq.weight only knows a single numeric value and cannot support per-device settings as io.weight does. A symlink wouldn't work. Not sure how you guys want to continue from here...

I just submitted this patch because I'm using it locally to fix it for me and wanted to give others the chance to benefit from it, but also hoping it could become an official interim solution until the kernel adopted a proper unified interface for both.

So this patch needs to be amended as soon as the kernel patch is merged?

@paolo-github but what does that mean for the userspace-facing API? Are you saying that in a kernel not so far off both the cfq and the bfq scheduler will expose the same set of cgroup attributes so that userspace doesn't have to care anymore?

@paolo-github but what does that mean for the userspace-facing API? Are you saying that in a kernel not so far off both the cfq and the bfq scheduler will expose the same set of cgroup attributes so that userspace doesn't have to care anymore?
Exactly. Still, don't forget that there is no cfq any longer, since 5.0. Thanks, Paolo

So io.bfq.weight goes away anyways and io.weight takes over for bfq? Or in other words: I can drop this patch once machines are migrated to 5.0 or later...

@paolo-github ok, so which kernel version would you estimate if all goes well this is solved in?

5.4, if maintainers reply in a reasonable time (the path has been out for 15 days).

So, for the record:

1. Kernels up to 5.4 (and maybe later) would need this work-around for properly using IO weights with bfq and systemd. It will take some time before that kernel version main-streams into distributions. Which next version is supposed to become an LTS version?
2. Will io.bfq.weight go away when the patch is merged? Or will it stay?
3. If it stays, will the change to support per-device weights through this interface be backported? I don't believe so because it would break user-space that already relies on it.

Then it looks like we should merge this... If the patch works, it will make things better until kernel 5.4. For many users that means maybe a year.

If the patch works, it will make things better until kernel 5.4

The nice thing is: If newer kernels drop io.bfq.weight in favor of properly interfacing io.weight to bfq, this patch automatically results in a silent no-op. Maybe I should add a small comment that this can be dropped at some time later?

Yes please.

Yes please.

Ok, here we go. Please check, hope all is fine. I also touched the NEWS file.

EDIT: Hmm, maybe better split in two patches? So NEWS doesn't become accidentally reverted at some time later?

LGTM, but let's wait for @poettering's opinion too.

This pull request introduces 1 alert when merging 21221ce into 06e9313 - view on LGTM.com

new alerts:

• 1 for FIXME comment

i must say, I am not a fan at all of compat kludges like this one, I would prefer to just sit this one out, since stopgaps like this tend to just stay in the code forever...

But OK.

@poettering I'll put a reminder into my calendar for checking this again in a year to take care of it.

Hi,
just an unenthusiastic update. In the last months, we have gone on implementing variations, asked by Jens and Tejun, on a solution to this confusing name issue. Yet, after proposing an apparently satisfying version two months ago, both Jens and Tejun have stopped replying [1]. I've asked for a reply several times, at no avail so far.

I've run out of options, apart from waiting. If someone wants to make their voice heard, in that thread or in a new one, that would be more than welcome. I also welcome any other suggestions.

[1] https://lkml.org/lkml/2019/10/1/1252

@paolo-github so, whtat's the latest on this? will this ever be resolved on the kernel side?

I'm not sure why this setting still exists separately anyways as cfq seems to be gone and replaced by bfq as the standard multiqueue scheduler, correct? I'm not sure if the other schedulers (mq-deadline, kyber etc) even support IO weights.