lkml.org 
[lkml]   [2005]   [Dec]   [28]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [RFC] CPU scheduler: Simplified interactive bonus mechanism
Ingo Molnar wrote:
> * Ingo Molnar <mingo@elte.hu> wrote:
>
>
>>* Peter Williams <pwil3058@bigpond.net.au> wrote:
>>
>>
>>>This patch implements a prototype version of a simplified interactive
>>>bonus mechanism. The mechanism does not attempt to identify
>>>interactive tasks and give them a bonus (like the current mechanism
>>>does) but instead attacks the problem that the bonuses are supposed to
>>>fix, unacceptable interactive latency, directly.
>>
>>i think we could give this one a workout in -mm, to see the actual
>>effects. Would you mind to merge this to -mm's scheduler queue, to right
>>after sched-add-sched_batch-policy.patch?
>
>
> i have done this for latest -mm, see the patch below (i also merged your
> patch to the SCHED_BATCH patch's effects), but the resulting kernel has
> really bad interactivity: e.g. simply starting 4 CPU hogs on a 2-CPU
> system slows down shell commands like 'ls' noticeably. So NACK for the
> time being.

OK. I didn't really think this was ready for the big time yet without
some refinement which is why I RFC'd it rather than posting it as a patch.

How good the interactive responsiveness really was one of my concerns as
it's hard to evaluate. Just because it seemed to work well on my system
doesn't mean that it works well everywhere. I did test it with 16 hard
spinners on my SMT workstation but I was mainly looking at things like X
responsiveness and the rythmbox music player and not shell commands.

I think that from a theoretical point of view shell commands won't do
well with this scheduler (as it stands) as they don't do many
interactive sleeps and hence are unlikely to accrue any bonuses. So
that means back to the drawing board. It also means that interactive
latency isn't the only important latency. Perhaps all latencies need to
be considered with interactive latencies being given more weight. (This
would be consistent with the current scheduler which only completely
discounts sleep that is marked TASK_NONINTERACTIVE and just heavily
discounts uninterruptible sleep.)

Thanks for the feed back. You've given me something to think about and
I think these issues can be addressed without very little extra
complexity. If not I'll just shelve the idea.

Peter
--
Peter Williams pwil3058@bigpond.net.au

"Learning, n. The kind of ignorance distinguishing the studious."
-- Ambrose Bierce
-
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: 2005-12-28 14:20    [W:3.864 / U:0.260 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site