From: Ingo Molnar <mingo@elte.hu>
To: "Toralf Förster" <toralf.foerster@gmx.de>
Cc: Mike Galbraith <efault@gmx.de>, Sam Ravnborg <sam@ravnborg.org>,
Peter Zijlstra <peterz@infradead.org>,
linux-kernel@vger.kernel.org
Subject: Re: (ondemand) CPU governor regression between 2.6.23 and 2.6.24
Date: Mon, 28 Jan 2008 14:18:23 +0100 [thread overview]
Message-ID: <20080128131823.GB8269@elte.hu> (raw)
In-Reply-To: <200801272214.49928.toralf.foerster@gmx.de>
Toralf, for me the group scheduler offers superior interactivity on my
laptop for a number of reasons. The biggest practical effect is because
it splits the CPU time between Xorg (root UID) and desktop apps. This
helps particularly well when there's compile jobs going on, etc. - Xorg
still gets a guaranteed share of CPU time which is a nice touch. The
mouse does not lag that much under load, etc. It's not always possible
to renice every aspect of my destop.
i wasnt using dnetc myself, so i never triggered your particular issue -
but i met a similar issue with the distcc user. I think it's more robust
in general to isolate the dnetc user a bit from the rest of the system -
even at nice +19 dnetc can interact with your desktop apps.
( In the long run, dnetc (and distcc, and all the other batch/clustering
apps) would automatically set their uid to a lower cpu_share value, so
this manual tweaking would not be needed. )
So if you have some time to play with this, could you please try the
following experiment. Put the following line into your
/etc/rc.d/rc.local file:
echo 2 > /sys/kernel/uids/`grep -w dnetc /etc/passwd | cut -d: -f3`/cpu_share
with group scheduling (CONFIG_FAIR_GROUP_SCHED=y) enabled. Also apply
the patch attached below as well - which fixes some interactivity
problems with group scheduling.
Could you try that kernel and compare it to a FAIR_GROUP_SCHED-disabled
kernel's interactivity, and send us your observations?
the group scheduler needs tuning in your case, but in the end, i believe
it can offer even better interactivity than what we had before - so it
would be nice if you could try it and compare.
If this still doesnt do the trick and the group scheduler is worse in
your testing then there's something else going on as well which we need
to fix. (even if you ultimately decide to disable the group scheduler)
At minimum we should be able to reach a "works just as well as with
group scheduling disabled" state. Thanks,
Ingo
Index: linux/kernel/sched_fair.c
===================================================================
--- linux.orig/kernel/sched_fair.c
+++ linux/kernel/sched_fair.c
@@ -520,7 +520,7 @@ place_entity(struct cfs_rq *cfs_rq, stru
if (!initial) {
/* sleeps upto a single latency don't count. */
- if (sched_feat(NEW_FAIR_SLEEPERS) && entity_is_task(se))
+ if (sched_feat(NEW_FAIR_SLEEPERS))
vruntime -= sysctl_sched_latency;
/* ensure we never gain time by being placed backwards. */
@@ -1106,7 +1106,11 @@ static void check_preempt_wakeup(struct
}
gran = sysctl_sched_wakeup_granularity;
- if (unlikely(se->load.weight != NICE_0_LOAD))
+ /*
+ * More easily preempt - nice tasks, while not making
+ * it harder for + nice tasks.
+ */
+ if (unlikely(se->load.weight > NICE_0_LOAD))
gran = calc_delta_fair(gran, &se->load);
if (pse->vruntime + gran < se->vruntime)
next prev parent reply other threads:[~2008-01-28 13:18 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-01-26 17:11 Tomasz Chmielewski
2008-01-26 18:46 ` Toralf Förster
2008-01-27 14:46 ` Srivatsa Vaddagiri
2008-01-27 15:06 ` Toralf Förster
2008-01-27 16:54 ` Srivatsa Vaddagiri
2008-01-27 16:57 ` Toralf Förster
2008-01-27 21:27 ` Peter Zijlstra
2008-01-27 22:32 ` Ingo Molnar
2008-01-28 8:38 ` Helge Hafting
2008-01-26 21:38 ` Toralf Förster
2008-01-26 21:45 ` Sam Ravnborg
[not found] ` <200801271200.04971.toralf.foerster@gmx.de>
[not found] ` <1201433167.22060.10.camel@homer.simson.net>
2008-01-27 12:39 ` Toralf Förster
2008-01-27 18:58 ` Mike Galbraith
2008-01-27 21:14 ` Toralf Förster
2008-01-27 21:25 ` Peter Zijlstra
2008-01-28 13:18 ` Ingo Molnar [this message]
2008-01-28 15:16 ` Toralf Förster
-- strict thread matches above, loose matches on Subject: below --
2008-01-26 14:06 Toralf Förster
2008-02-04 0:32 ` Andrew Morton
2008-02-04 0:36 ` Andrew Morton
2008-02-04 17:44 ` Pallipadi, Venkatesh
2008-02-04 19:18 ` Toralf Förster
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20080128131823.GB8269@elte.hu \
--to=mingo@elte.hu \
--cc=efault@gmx.de \
--cc=linux-kernel@vger.kernel.org \
--cc=peterz@infradead.org \
--cc=sam@ravnborg.org \
--cc=toralf.foerster@gmx.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®