Re: [RFC][PATCH 3/9] CPU controller - Adds timeslice scaling

[Mike Galbraith]

On Fri, 2006-04-21 at 17:56 +0900, MAEDA Naoaki wrote:
> Mike Galbraith wrote:
> > Why does timeslice scaling become undesirable if TASK_INTERACTIVE(p)?
> > With this barrier, you will completely disable scaling for many loads.
> 
> Because interactive tasks tend to spend very small timeslice at one
> time, scaling timeslice for these tasks is not effective to control
> CPU spent.

True.

> Or, do you say that lots of non-interactive tasks are misjudged as
> TASK_INTERACTIVE(p)?

Almost.  TASK_INTERACTIVE(p) doesn't mean the task is an interactive
task, only that it sleeps enough that it may be.  Interactive tasks can
generally be categorized as doing quite a bit of sleeping, but so do
other things.  HTTP/FTP daemons etc etc.

In the presence of a mixed load with several "interactive" components,
timeslice scaling can only do harm to throughput by further fragmenting
the already shattered time a task spends on cpu.  You don't want to
increase the context switch rate if you want throughput.
 
> > Is it possible you meant !rt_task(p)?
> > 
> > (The only place I can see scaling as having a large effect is on gobs of
> > non-sleeping tasks.  Slice width doesn't mean much otherwise.)
> 
> Yes. But these non-sleeping CPU-hog tasks tend to dominant CPU, so
> it is worth controlling them.

Time spent in the expired array limits the !TASK_INTERACTIVE(p).  In a
mixed load, the sleeping task component is the one which needs
controlling, because it will always preempt and get it's share of cpu.
In a pure hog load, the scheduler is pure round-robin, so no scaling is
needed.  It's the sleep deprived who need protection from the swarms of
preempt enabled.

	-Mike

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