>>>- 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 CFQ > scheduler. Shailabh is currently working on porting that controller to > f-series. can you explain what was changed by CKRM there? Did you made it to control ASYNC read/writes? I don't think so... Do you have any plots on what is concurrent bandwidth is depending on weights? Because, our measurements show that CFQ is not ideal and behaves poorly when prio 0,5,6,7 are used :/ Only 1,2,3,4 are really linear-scalable... >>>3) 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 > i started looking at UBC. They provide only max limits, not min > guarantees, right ? 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. Kirill _______________________________________________ ckrm-tech mailing list https://lists.sourceforge.net/lists/listinfo/ckrm-tech
