LKML Archive on
help / color / mirror / Atom feed
From: Peter Zijlstra <>
To: Dhaval Giani <>
Cc: Ingo Molnar <>,
	Srivatsa Vaddagiri <>,
	lkml <>
Subject: Re: Regression in latest sched-git
Date: Tue, 12 Feb 2008 20:40:08 +0100	[thread overview]
Message-ID: <1202845208.6247.82.camel@lappy> (raw)
In-Reply-To: <>

On Wed, 2008-02-13 at 00:23 +0530, Dhaval Giani wrote:
> Hi Ingo,
> I've been running the latest sched-git through some tests. Here is
> essentially what I am doing,
> 1. Mount the control group
> 2. Create 3-4 groups
> 3. Start kernbench inside each group
> 4. Run cpu hogs in each group
> Essentially the idea is to see how the system responds under extreme CPU
> load.

> This is what I get (and this is in a shell which belongs to the root
> group)
> [root@llm11 ~]# time sleep 1
> real    0m1.212s
> user    0m0.004s
> sys     0m0.000s

> On the sched-devel tree that I have, the same gives me following
> results.
> [root@llm11 ~]# time sleep 1
> real    0m1.057s
> user    0m0.000s
> sys     0m0.004s

Yes, latency isolation is the one thing I had to sacrifice in order to
get the normal latencies under control.

The problem with the old code is that under light load: a kernel make
-j2 as root, under an otherwise idle X session, generates latencies up
to 120ms on my UP laptop. (uid grouping; two active users: peter, root).

Others have reported latencies up to 300ms, and Ingo found a 700ms
latency on his machine.

The source for this problem is I think the vruntime driven wakeup
preemption (but I'm not quite sure). The other things that rely on
global vruntime are sleeper fairness and yield. Now while I can't
possibly care less about yield, the loss of sleeper fairness is somewhat
sad (NB. turning it off with the old group scheduling does improve life

So my first attempt at getting a global vruntime was flattening the
whole RQ structure, you can see that patch in sched.git (I really ought
to have posted that, will do so tomorrow).

With the experience gained from doing that, I think it might be possible
to construct a hierarchical RQ model that has synced vruntime; but
thinking about that still makes my head hurt.

Anyway, yes, its not ideal, but it does the more common case of light
load much better - I basically had to tell people to disable
CONFIG_FAIR_GROUP_SCHED in order to use their computer, which is sad,
because its the default and we want it to be the default in the cgroup

So yes, I share your concern, lets work on this together.

  reply	other threads:[~2008-02-12 19:40 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-02-12 18:53 Dhaval Giani
2008-02-12 19:40 ` Peter Zijlstra [this message]
2008-02-13  3:00   ` Srivatsa Vaddagiri
2008-02-13 12:51     ` Peter Zijlstra
2008-02-13 16:34       ` Dhaval Giani
2008-02-13 16:37         ` Dhaval Giani
2008-02-13 16:43           ` Peter Zijlstra
2008-02-13 17:06         ` Srivatsa Vaddagiri
2008-02-14 11:20 ` Peter Zijlstra

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:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1202845208.6247.82.camel@lappy \ \ \ \ \ \
    --subject='Re: Regression in latest sched-git' \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).