mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
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)

  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®