On Tue, Jan 31, 2023 at 4:11 PM Christoph Hellwig <hch@xxxxxxxxxxxxx> wrote: > On Tue, Jan 31, 2023 at 03:05:20PM +0100, Linus Walleij wrote: > > To be clear, "works better" in this context means, solving a problem > > for the interactive user, preventing random freezing of the UI on > > resource-limited (memory, disk throughput) systems under high > > I/O load. > > Which already has nothing to do with the mmc driver. And the rest > of your mail makes this even more clear. You want bfq for interactive > systems with little resources and really shitty storage device, which > just happen to use mmc in your use case. First time it helped me it was rotating rust actually, but yeah MMC/SD is one of those. > My use case for sd cards OTOH is extremely resource constrained systems > where I absolutely do not want a bloated I/O scheduler. In fact I'd > love to be able to even compile the infrastructure for them away. Hm I think you're mixing up different resource constraints here (that your storage is slow does not mean your CPU is weak or that you have little RAM) but I see your point. What I think a lot of the debate is about is "abundance of resources" systems vs "constrained resources" systems. Some are hard to keep busy (such as MQ devices) other are hard to get access through because of constant overload (such as MMC/SD-cards). > In other words: you want distro policy to use bfq for your use case, > but that has no business being in the Kconfig. Well *using* it is still the matter of a udev rule for an ordinary distro as we have no mechanism to instruct the kernel to use any specific scheduler with some subsystem. (I think we should have some hint for that, for slow single channel devices for example.) The Kconfig change is mainly about making it available for use, for systems with MMC/SD-card drivers. Yours, Linus Walleij
