> A better way to achieve the desired group cpu usage IMHO would be to
> adjust nice level of members at slice refresh time. This way, you get
> the timeslice scaling and priority adjustment all in one.
>
> (I think I would do both actually, with nice level being preferred such
> that dynamic priority spread within the group isn't flattened, which can
> cause terminal starvation within the group, unless really required.)
I am actually working on something more or less like that as part of my
licentiate (half time PhD) thesis. In the thesis I want to control CPU
resources using a control theoretic approach. The results so far are
very promising, but my code is not very mature yet. I plan to have my
thesis ready during this summer, so if anyone is interested I can mail
you a copy. If I have the time after that, I will try to incorporate my
code into the CKRM framework.
/Martin Andersson
-
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]
