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



-------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
ckrm-tech mailing list
https://lists.sourceforge.net/lists/listinfo/ckrm-tech

Reply via email to