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.
Or, do you say that lots of non-interactive tasks are misjudged as
TASK_INTERACTIVE(p)?
> 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.
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]
