Nick Piggin wrote:
So, from my POV, I would like to be convinced of the need for this first.
I would really love to be able to keep core kernel simple and fast even if
it means edge cases might need to use a slightly different solution.
We currently use a heavily modified CKRM version "e".
The "resource groups" (formerly known as CKRM) cpu controls express what
we'd like to do, but they aren't nearly accurate enough. We don't make
use the limits, but we do use per-cpu guarantees, along with the
hierarchy concept.
Our engineering guys need to be able to make cpu guarantees for the
various type of processes. "main server app gets 90%, these fault
handling guys normally get 2% but should be able to burst to 100% for up
to 100ms, that other group gets 5% in total, but a subset of them should
get priority over the others, and this little guy here should only be
guaranteed .5% but it should take priority over everything else on the
system as long as it hasn't used all its allocation".
Ideally they'd really like sub percentage (.1% would be nice, but .5% is
proably more realistic) accuracy over the divisions. This should be
expressed per-cpu, and tasks should be migrated as necessary to maintain
fairness. (Ie, a task belonging to a group with 50% on each cpu should
be able to run essentially continuously, bouncing back and forth between
cpus.) In our case, predictability/fairness comes first, then performance.
If a method is accepted into mainline, it would be nice to have NPTL
support it as a thread attribute so that different threads can be in
different groups.
Chris
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
