![]() | |||||||||||||
Messages in this thread |
On Fri, 28 Apr 2006 08:59:49 +0200 Mike Galbraith <efault@gmx.de> wrote: > On Fri, 2006-04-28 at 14:48 +0900, MAEDA Naoaki wrote: > > Hi Mike, > > > > On Fri, 28 Apr 2006 07:25:35 +0200 > > Mike Galbraith <efault@gmx.de> wrote: > > > > > On Fri, 2006-04-28 at 10:37 +0900, MAEDA Naoaki wrote: > > > > Andrew, > > > > > > > > This patchset adds a CPU resource controller on top of Resource Groups. > > > > The CPU resource controller manages CPU resources by scaling timeslice > > > > allocated for each task without changing the algorithm of the O(1) > > > > scheduler. > > > > > > > > Please consider these for inclusion in -mm tree. > > > > > > This patch set professes to be a resource controller, yet 100% of high > > > priority tasks are uncontrolled. Distribution of CPU among high > > > priority tasks isn't important, but distribution of what they leave > > > behind is? > > > > Do you mean niced tasks are uncontrolled by the controller? > > TASK_INTERACTIVEs are left untouched intentionally, but niced tasks > > are also controlled. > > Until they attain interactive status. Note that attaining this status > requires only one sleep, and once attained, it can be sustained. I > don't know what the current exact numbers are, but until recently, the > numbers were that once sleep_avg became full, a non-niced task could > sustain ~95% cpu indefinitely. > > You simply cannot ignore interactive tasks. At the very least, you have > to disallow requeue if the resource limit has been exceeded, otherwise, > this patch set is non-functional. It can be easily implemented on top of the current code. Do you know a good sample program that is judged as interactive but consumes lots of cpu? Thanks, MAEDA Naoaki - 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/ | ||||||||||||
| Last update: 2006-04-28 09:29 [from the cache] ©2003-2008 | |||||||||||||