> Mike Galbraith wrote:
> > On Fri, 2006-04-21 at 11:27 +0900, [email protected] wrote:
> >> Index: linux-2.6.17-rc2/kernel/sched.c
> >> ===================================================================
> >> --- linux-2.6.17-rc2.orig/kernel/sched.c
> >> +++ linux-2.6.17-rc2/kernel/sched.c
> >> @@ -173,10 +173,17 @@
> >>
> >> static unsigned int task_timeslice(task_t *p)
> >> {
> >> + unsigned int timeslice;
> >> +
> >> if (p->static_prio < NICE_TO_PRIO(0))
> >> - return SCALE_PRIO(DEF_TIMESLICE*4, p->static_prio);
> >> + timeslice = SCALE_PRIO(DEF_TIMESLICE*4, p->static_prio);
> >> else
> >> - return SCALE_PRIO(DEF_TIMESLICE, p->static_prio);
> >> + timeslice = SCALE_PRIO(DEF_TIMESLICE, p->static_prio);
> >> +
> >> + if (!TASK_INTERACTIVE(p))
> >> + timeslice = cpu_rc_scale_timeslice(p, timeslice);
> >> +
> >> + return timeslice;
> >> }
> >
> > 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.
It was not good explanation. Let me restate that.
The effect of shortening timeslice is to let the task be expired soon
by shortening
its remainder timeclice, so it still works even if the task consome very small
timeslice at one time. However, expired TASK_INTERACTIVE tasks will be requeued
to the active for a while by the scheduler, so shortening timeslice
doesn't work well for
TASK_INTERACTIVE tasks.
Thanks,
MAEDA Naoaki
-
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]
