Hello, On Fri, Oct 15, 2021 at 09:07:45AM +0200, Odin Hultgren van der Horst wrote: > > IIUC, the application would have to be collaborative anyway (dividing > > threads into cgroups) and given you're concered about reads, > > set_ioprio(2) might be enough for this case. One problem there is that set_ioprio(2) only works w/ bfq. > > Also, if you've seen starvation (likely depends on IO scheduler), you > > may raise this with linux-block ML. > > I also want to be able to limit amount of io for a given thread, just > like you could to with io.max. So a given client cant just use all my io > even though there is no competing thread. This isn't what cgroup is too useful at right now. CPU control is an exception partly due to historical reasons but it's silly to enable support for per-thread IO control when a chunk as big as buffered writes is not only missing but doesn't even have a plausible future path for support. Another rather fundamental problem is that cgroup interface ends up entangling application behavior with system admin operations - e.g. whether IO control is available for a given application is determined by not just the kernel configuration but how the system's cgroup hierarchy is configured at the moment and an application's configurations can be wiped out by system configuration changing. Being able to extend resource control to per-thread level can definitely be useful but we'd need a lot more work in providing a usable programmable interface which can make cgroup system configuration transparent to the applications so that applications can basically do something like set_ioprio(2) and have resource control working as best as possible on top of the system configuration at the moment. Thanks. -- tejun
