On Tue, Jun 18, 2024 at 11:17:44AM +0800, Yu Kuai wrote: > The motivation is that iocost is not used widely in our production, and > some customers don't want to increase kernel size to enable iocost that > they will never use, and it'll be painful to maintain a new downstream > kernel. Hence it'll be beneficially to build iocost as kernel module: > > - Kernel Size and Resource Usage, modules are loaded only when their > specific functionality is required. > > - Flexibility and Maintainability, allows for dynamic loading and unloading > of modules at runtime without the need to recompile and restart the kernel, > for example we can just replace blk-iocost.ko to fix iocost CVE in our > production environment. Given the amount of new exports and infrastructure it adds this still feels like a bad tradeoff.
