- disk I/O bandwidth:
we started to use CFQv2, but it is quite poor in this regard. First, it doesn't prioritizes writes and async disk operations :( And even for sync reads we found some problems we work on now...
CKRM (on e-series) had an implementation based on a modified CFQcan you explain what was changed by CKRM there? Did you made it to control ASYNC read/writes? I don't think so...
scheduler. Shailabh is currently working on porting that controller to
f-series.
they provide also vmpages guarantees and guarantees against OOM killer. (vmguarpages and oomguarpages) i.e. if container consumes less than X pages it won't be killed by OOM killer. Only if there no any other container to select. I.e. we have 2-level OOM.i started looking at UBC. They provide only max limits, not min3) memory and other resources.
- memory
- files
- signals and so on and so on.
For example, in OpenVZ we have user resource beancounters (original author is Alan Cox), which account the following set of parameters:
kernel memory (vmas, page tables, different structures etc.), dcache
guarantees, right ?