| Message ID | 6fe53222-876c-4deb-b4e1-453eb689a9f3@kernel.dk (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | MAINTAINERS: move the BFQ io scheduler to orphan state | expand |
On 9/3/24 8:53 AM, Jens Axboe wrote: > Nobody is maintaining this code, and it just falls under the umbrella > of block layer code. But at least mark it as such, in case anyone wants > to care more deeply about it and assume the responsibility of doing so. > > Signed-off-by: Jens Axboe <axboe@kernel.dk> > > --- > > diff --git a/MAINTAINERS b/MAINTAINERS > index 42decde38320..4a857a125d6e 100644 > --- a/MAINTAINERS > +++ b/MAINTAINERS > @@ -3781,10 +3781,8 @@ F: Documentation/filesystems/befs.rst > F: fs/befs/ > > BFQ I/O SCHEDULER > -M: Paolo Valente <paolo.valente@unimore.it> > -M: Jens Axboe <axboe@kernel.dk> > L: linux-block@vger.kernel.org > -S: Maintained > +S: Orphan > F: Documentation/block/bfq-iosched.rst > F: block/bfq-* > Reviewed-by: Bart Van Assche <bvanassche@acm.org>
On 9/3/24 8:53 AM, Jens Axboe wrote: > Nobody is maintaining this code, and it just falls under the umbrella > of block layer code. But at least mark it as such, in case anyone wants > to care more deeply about it and assume the responsibility of doing so. > > Signed-off-by: Jens Axboe <axboe@kernel.dk> > > --- > > diff --git a/MAINTAINERS b/MAINTAINERS > index 42decde38320..4a857a125d6e 100644 > --- a/MAINTAINERS > +++ b/MAINTAINERS > @@ -3781,10 +3781,8 @@ F: Documentation/filesystems/befs.rst > F: fs/befs/ > > BFQ I/O SCHEDULER > -M: Paolo Valente <paolo.valente@unimore.it> > -M: Jens Axboe <axboe@kernel.dk> > L: linux-block@vger.kernel.org > -S: Maintained > +S: Orphan > F: Documentation/block/bfq-iosched.rst > F: block/bfq-* To the memstick and mmc maintainers, should the Kconfig files for these drivers perhaps be updated? This is what I found by searching for IOSCHED_BFQ: $ git grep -nH 'imply.*BFQ' drivers/memstick/core/Kconfig:23: imply IOSCHED_BFQ drivers/memstick/core/Kconfig:33: imply IOSCHED_BFQ drivers/mmc/core/Kconfig:40: imply IOSCHED_BFQ Thanks, Bart.
On Tue, 3 Sept 2024 at 17:54, Jens Axboe <axboe@kernel.dk> wrote: > > Nobody is maintaining this code, and it just falls under the umbrella > of block layer code. But at least mark it as such, in case anyone wants > to care more deeply about it and assume the responsibility of doing so. > > Signed-off-by: Jens Axboe <axboe@kernel.dk> I haven't spoken to Paolo recently (just dropped him an email), but I was under the impression that he intended to keep an eye on the BFQ scheduler. BTW, why didn't you cc him? Kind regards Uffe > > --- > > diff --git a/MAINTAINERS b/MAINTAINERS > index 42decde38320..4a857a125d6e 100644 > --- a/MAINTAINERS > +++ b/MAINTAINERS > @@ -3781,10 +3781,8 @@ F: Documentation/filesystems/befs.rst > F: fs/befs/ > > BFQ I/O SCHEDULER > -M: Paolo Valente <paolo.valente@unimore.it> > -M: Jens Axboe <axboe@kernel.dk> > L: linux-block@vger.kernel.org > -S: Maintained > +S: Orphan > F: Documentation/block/bfq-iosched.rst > F: block/bfq-* > > -- > Jens Axboe > >
On 9/4/24 7:27 AM, Ulf Hansson wrote: > On Tue, 3 Sept 2024 at 17:54, Jens Axboe <axboe@kernel.dk> wrote: >> >> Nobody is maintaining this code, and it just falls under the umbrella >> of block layer code. But at least mark it as such, in case anyone wants >> to care more deeply about it and assume the responsibility of doing so. >> >> Signed-off-by: Jens Axboe <axboe@kernel.dk> > > I haven't spoken to Paolo recently (just dropped him an email), but I > was under the impression that he intended to keep an eye on the BFQ > scheduler. But he hasn't, it's been a long time since he was involved. I've been applying patches on an as-needed basis, but effectively nobody has been maintaining it for probably 2 years at this point. > BTW, why didn't you cc him? That was an oversight, I think because I haven't seen anything from him in a long time to assumed he was awol.
+ Paolo On Wed, 4 Sept 2024 at 15:47, Jens Axboe <axboe@kernel.dk> wrote: > > On 9/4/24 7:27 AM, Ulf Hansson wrote: > > On Tue, 3 Sept 2024 at 17:54, Jens Axboe <axboe@kernel.dk> wrote: > >> > >> Nobody is maintaining this code, and it just falls under the umbrella > >> of block layer code. But at least mark it as such, in case anyone wants > >> to care more deeply about it and assume the responsibility of doing so. > >> > >> Signed-off-by: Jens Axboe <axboe@kernel.dk> > > > > I haven't spoken to Paolo recently (just dropped him an email), but I > > was under the impression that he intended to keep an eye on the BFQ > > scheduler. > > But he hasn't, it's been a long time since he was involved. I've been > applying patches on an as-needed basis, but effectively nobody has > been maintaining it for probably 2 years at this point. I don't think we should expect him to do active development, but rather just to keep an eye on it from maintenance point of view. Let me try to get in contact with him for an update. > > > BTW, why didn't you cc him? > > That was an oversight, I think because I haven't seen anything from > him in a long time to assumed he was awol. I looked at the last year or so at the linux-block mailing-list and it seems most patches for bfq aren't being sent to his email. :-( Ohh well, let's see what we can do about this. Surely BFQ is being used out there, so it would really be a pity if nobody takes good care of it. Kind regards Uffe
On 9/4/24 7:59 AM, Ulf Hansson wrote: > + Paolo > > On Wed, 4 Sept 2024 at 15:47, Jens Axboe <axboe@kernel.dk> wrote: >> >> On 9/4/24 7:27 AM, Ulf Hansson wrote: >>> On Tue, 3 Sept 2024 at 17:54, Jens Axboe <axboe@kernel.dk> wrote: >>>> >>>> Nobody is maintaining this code, and it just falls under the umbrella >>>> of block layer code. But at least mark it as such, in case anyone wants >>>> to care more deeply about it and assume the responsibility of doing so. >>>> >>>> Signed-off-by: Jens Axboe <axboe@kernel.dk> >>> >>> I haven't spoken to Paolo recently (just dropped him an email), but I >>> was under the impression that he intended to keep an eye on the BFQ >>> scheduler. >> >> But he hasn't, it's been a long time since he was involved. I've been >> applying patches on an as-needed basis, but effectively nobody has >> been maintaining it for probably 2 years at this point. > > I don't think we should expect him to do active development, but > rather just to keep an eye on it from maintenance point of view. I never expect active development, there may not be a need for it. But basic maintenance is definitely the maintainers role. As that hasn't been happening for quite a while, I'd consider it orphaned. >>> BTW, why didn't you cc him? >> >> That was an oversight, I think because I haven't seen anything from >> him in a long time to assumed he was awol. > > I looked at the last year or so at the linux-block mailing-list and it > seems most patches for bfq aren't being sent to his email. :-( > > Ohh well, let's see what we can do about this. Surely BFQ is being > used out there, so it would really be a pity if nobody takes good care > of it. Probably not a whole lot I think, at least on the prod side experiences with BFQ haven't been good. So there's definitely fixes to do, and I was happy to see fixes being sent in recently to address some concerns. Someone with actual customers using it and finding issues, or someone actually using it.
On Wed, Sep 4, 2024 at 4:07 PM Jens Axboe <axboe@kernel.dk> wrote: > On 9/4/24 7:59 AM, Ulf Hansson wrote: >> Surely BFQ is being > > used out there, so it would really be a pity if nobody takes good care > > of it. > > Probably not a whole lot I think, at least on the prod side experiences > with BFQ haven't been good. Which production? For singlequeue devices it is pretty widespread. It is used in Fedora, RedHat and SuSE as default scheduler for any /dev/sdN, /dev/srN and /dev/mmcblkN (i.e. anything singlequeue). Example from my main development machine with Fedora 40: $ cat /sys/block/sda/queue/scheduler none mq-deadline kyber [bfq] Laptop with MMC card reader: $ cat /sys/block/mmcblk0/queue/scheduler none mq-deadline kyber [bfq] Maybe we should propose these rules to the main udev repository so that they also go into Debian and we get even wider use? It is also used by default in all Chromebooks using eMMC as storage. I think even all Android devices using eMMC is using it but that is hard to check. Yours, Linus Walleij
On 9/5/24 7:03 AM, Linus Walleij wrote: > On Wed, Sep 4, 2024 at 4:07?PM Jens Axboe <axboe@kernel.dk> wrote: >> On 9/4/24 7:59 AM, Ulf Hansson wrote: > >>> Surely BFQ is being >>> used out there, so it would really be a pity if nobody takes good care >>> of it. >> >> Probably not a whole lot I think, at least on the prod side experiences >> with BFQ haven't been good. > > Which production? For singlequeue devices it is pretty widespread. We tried it at one point internally at Meta, and it was not pretty. Now it's just disabled so people don't inadvertently pick it (as some people like to do when fiddling with things). > It is used in Fedora, RedHat and SuSE as default scheduler for any > /dev/sdN, /dev/srN and /dev/mmcblkN (i.e. anything singlequeue). > > Example from my main development machine with Fedora 40: > $ cat /sys/block/sda/queue/scheduler > none mq-deadline kyber [bfq] > Laptop with MMC card reader: > $ cat /sys/block/mmcblk0/queue/scheduler > none mq-deadline kyber [bfq] > > Maybe we should propose these rules to the main udev repository > so that they also go into Debian and we get even wider use? I know you like to push for it to be the default, and I always push back because I don't think it's stable enough for that, and now we have the added complication that it hasn't been maintained for quite a while. So no, I don't think so. There are some bugzilla entries too that never got resolved or moved very far. Some of those may now be invalid, maybe not. Impossible to know.
On Thu, Sep 5, 2024 at 4:58 PM Jens Axboe <axboe@kernel.dk> wrote: > On 9/5/24 7:03 AM, Linus Walleij wrote: > > Which production? For singlequeue devices it is pretty widespread. > > We tried it at one point internally at Meta, and it was not pretty. I didn't know you used any singlequeue devices. If you used it on multiqueue devices, well that can't be recommended. > > Maybe we should propose these rules to the main udev repository > > so that they also go into Debian and we get even wider use? > > I know you like to push for it to be the default, and I always push back > because I don't think it's stable enough for that, and now we have the > added complication that it hasn't been maintained for quite a while. > So no, I don't think so. The reason I like it personally is that it has actually saved me from crashing my machine by preserving interactivity on a (single queue) device: https://people.kernel.org/linusw/bfq-saved-me-from-thrashing For Androids and chromebooks it keeps the device interactive during heavy disk (eMMC) activity, such as when Android updates a pile of apps (.apk files). > There are some bugzilla entries too that never got resolved or moved > very far. Some of those may now be invalid, maybe not. Impossible to > know. OK fair enough, I hear there is a maintainer that will look after it now. Yours, Linus Walleij
On 9/5/24 11:05 AM, Linus Walleij wrote: > For Androids and chromebooks it keeps the device interactive > during heavy disk (eMMC) activity, such as when Android > updates a pile of apps (.apk files). Is that issue perhaps specific to eMMC devices? I have never seen an Android device with UFS storage becoming unresponsive during app updates. Additionally, now that the mq-deadline I/O scheduler supports I/O priorities, it is easy to give foreground I/O a higher priority in Android than background I/O. All that is needed is to add something like the following in an .rc file that is executed during boot: write /dev/blkio/blkio.prio.class promote-to-rt Bart.
On 9/5/24 12:05 PM, Linus Walleij wrote: > On Thu, Sep 5, 2024 at 4:58?PM Jens Axboe <axboe@kernel.dk> wrote: >> On 9/5/24 7:03 AM, Linus Walleij wrote: > >>> Which production? For singlequeue devices it is pretty widespread. >> >> We tried it at one point internally at Meta, and it was not pretty. > > I didn't know you used any singlequeue devices. > > If you used it on multiqueue devices, well that can't be recommended. Of course we have single queue devices, anything that isn't nvme is basically single queue. >>> Maybe we should propose these rules to the main udev repository >>> so that they also go into Debian and we get even wider use? >> >> I know you like to push for it to be the default, and I always push back >> because I don't think it's stable enough for that, and now we have the >> added complication that it hasn't been maintained for quite a while. >> So no, I don't think so. > > The reason I like it personally is that it has actually saved me from > crashing my machine by preserving interactivity on a (single queue) > device: > https://people.kernel.org/linusw/bfq-saved-me-from-thrashing I'd consider that largely anecdotal at this point. > For Androids and chromebooks it keeps the device interactive > during heavy disk (eMMC) activity, such as when Android > updates a pile of apps (.apk files). I'm somewhat dubious that that problem could not be solved in a much simpler way than what is BFQ.
diff --git a/MAINTAINERS b/MAINTAINERS index 42decde38320..4a857a125d6e 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -3781,10 +3781,8 @@ F: Documentation/filesystems/befs.rst F: fs/befs/ BFQ I/O SCHEDULER -M: Paolo Valente <paolo.valente@unimore.it> -M: Jens Axboe <axboe@kernel.dk> L: linux-block@vger.kernel.org -S: Maintained +S: Orphan F: Documentation/block/bfq-iosched.rst F: block/bfq-*
Nobody is maintaining this code, and it just falls under the umbrella of block layer code. But at least mark it as such, in case anyone wants to care more deeply about it and assume the responsibility of doing so. Signed-off-by: Jens Axboe <axboe@kernel.dk> ---