Ingo Molnar wrote:
* Ingo Molnar <[email protected]> wrote:
* Peter Williams <[email protected]> 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 [email protected]
"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 [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]
