Re: [ckrm-tech] [RFC 3/5] sched: Add CPU rate hard caps

[Kirill Korotaev <dev@sw.ru>]

> > > - 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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/