Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > linux.debian.kernel > #86567 > unrolled thread

Bug#946791: io.weight cannot be enabled in recent Debian kernel package

Started bySalvatore Bonaccorso <carnil@debian.org>
First post2025-03-23 09:00 +0100
Last post2025-04-23 04:00 +0200
Articles 2 — 2 participants

Back to article view | Back to linux.debian.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.


Contents

  Bug#946791: io.weight cannot be enabled in recent Debian kernel package Salvatore Bonaccorso <carnil@debian.org> - 2025-03-23 09:00 +0100
    Bug#946791: io.weight cannot be enabled in recent Debian kernel package Ben Hutchings <ben@decadent.org.uk> - 2025-04-23 04:00 +0200

#86567 — Bug#946791: io.weight cannot be enabled in recent Debian kernel package

FromSalvatore Bonaccorso <carnil@debian.org>
Date2025-03-23 09:00 +0100
SubjectBug#946791: io.weight cannot be enabled in recent Debian kernel package
Message-ID<Ktopr-84LM-1@gated-at.bofh.it>
Hi

On Wed, Mar 17, 2021 at 03:13:59PM +0100, Michael Biebl wrote:
> Control: retitle -1 Please enable CONFIG_IOSCHED_BFQ=y
> 
> On Thu, 26 Dec 2019 23:17:13 +0900 Ryutaroh Matsumoto
> <ryutaroh.matsumoto@nagoya-u.jp> wrote:
> > Source: linux
> > Followup-For: Bug #946791
> > Control: tags -1 + patch
> > 
> > Dear Maintainer,
> > 
> > I reported that IOWeight config item in systemd has no effect
> > on recent Debian kernels. I found the root cause.
> > io.weight was changed to io.bfq.weight, and recent systemd sets
> > values of IOWeight to io.bfq.weight as
> > 
> >
> https://github.com/systemd/systemd/commit/2dbc45aea747f25cc1c3848fded2ec0062f96bcf
> > 
> > For io.bfq.weight to appear in cgroup v2 filesystem, the bfq kernel
> > module must be loaded. Addition of "bfq" to /etc/initramfs-
> tools/modules
> > solved this issue. Since the systemd needs bfq module to be loaded,
> > changing CONFIG_IOSCHED_BFQ=m to CONFIG_IOSCHED_BFQ=y in kernel
> config
> > seems suitable.
> > 
> > If the Debian kernel team considers this issue to be handled by
> another
> > package, e.g. initramfs-tools or systemd, please reassign this.
> > If this issue is considered not being a bug, please close this.
> > 
> 
> Fwiw, the fedora kernel in F33 uses
> 
> # grep CONFIG_IOSCHED_BFQ /boot/config-5.10.22-200.fc33.x86_64 
> CONFIG_IOSCHED_BFQ=y
> 
> I think using CONFIG_IOSCHED_BFQ=y instead of loading it via initramfs-
> tools makes more sense (assuming it is safe to enable).

it has passed a substantial amount of time and we did not respond,
apologies about that.

In my opinion we should leave it as module, people wanting to use that
setup can load the module by own means and do additional configuration
selecting the bfq scheduler, and think resepctive units will as well
need to enable the IOAccounting (correct me if I'm wrong)?

Given this reply now, and time permitting we might discuss it in our
next kernel-team weekly meeting.

Regards,
Salvatore

[toc] | [next] | [standalone]


#86955

FromBen Hutchings <ben@decadent.org.uk>
Date2025-04-23 04:00 +0200
Message-ID<KExz3-fxvk-3@gated-at.bofh.it>
In reply to#86567

[Multipart message — attachments visible in raw view] — view raw

Control: tag -1 moreinfo

On Sun, 23 Mar 2025 08:46:28 +0100 Salvatore Bonaccorso
<carnil@debian.org> wrote:
[...]
> it has passed a substantial amount of time and we did not respond,
> apologies about that.
> 
> In my opinion we should leave it as module, people wanting to use that
> setup can load the module by own means and do additional configuration
> selecting the bfq scheduler, and think resepctive units will as well
> need to enable the IOAccounting (correct me if I'm wrong)?
> 
> Given this reply now, and time permitting we might discuss it in our
> next kernel-team weekly meeting.

We discussed this in a kernel team meeting and I agreed to look at what
was going on here.

In a test VM with 6.12.16-amd64:

- When I enable the "io" controller for a cgroup, I see an "io.weight"
  attribute in that cgroup.  So the originally reported problem has been
  fixed.

- With bfq not yet loaded, I can still set it as a scheduler and the
  module is auto-loaded:

      # cd /sys/class/block/vda/queue
      # cat scheduler 
      [none] mq-deadline 
      # echo bfq > scheduler 
      # cat scheduler 
      none mq-deadline [bfq] 

- After that, the cgroup also has an "io.bfq.weight" attribute.

systemd tries to set both attributes, which should cover devices with
BFQ and other schedulers.  But I see a problem with this sequence of
events:

1. systemd creates the cgroup for a service and sets its "io.weight"
attribute only, as bfq is not yet loaded.

2. The scheduler of a block device that the service will use is changed
to "bfq".  The bfq module is loaded and this cgroup gets an
"io.bfq.weight" attribute, but with a default value.

So far as I can see, neither the kernel nor systemd will synchronise the
added "io.bfq.weight" attribute with the "io.weight" attribute in step
2.  Whereas if bfq was built-in, this wouldn't be a problem.

Ryutaroh, do you consider your bug report to be fixed, or is the problem
I described above part of the bug?

Ben.

-- 
Ben Hutchings
The two most common things in the universe are hydrogen and stupidity.

[toc] | [prev] | [standalone]


Back to top | Article view | linux.debian.kernel


csiph-web