public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Srivatsa Vaddagiri <vatsa@linux.vnet.ibm.com>
To: Toralf.=?iso-8859-1?Q?F=F6rster_=3Ctoralf=2Efoerster=40gmx=2Ede=3E?=@snowy.in.ibm.com
Cc: Tomasz Chmielewski <mangoo@wpkg.org>,
	linux-kernel@vger.kernel.org, Ingo Molnar <mingo@elte.hu>,
	a.p.zijlstra@chello.nl, dhaval@linux.vnet.ibm.com
Subject: Re: (ondemand) CPU governor  regression between 2.6.23 and 2.6.24
Date: Sun, 27 Jan 2008 22:24:00 +0530	[thread overview]
Message-ID: <20080127165400.GB1044@linux.vnet.ibm.com> (raw)
In-Reply-To: <200801271606.19862.toralf.foerster@gmx.de>

On Sun, Jan 27, 2008 at 04:06:17PM +0100, Toralf Förster wrote:
> > The third line (giving overall cpu usage stats) is what is interesting here.
> > If you have more than one cpu, you can get cpu usage stats for each cpu
> > in top by pressing 1. Can you provide this information with and w/o 
> > CONFIG_FAIR_GROUP_SCHED?
> 
> This is what I get if I set CONFIG_FAIR_GROUP_SCHED to "y"
> 
> top - 16:00:59 up 2 min,  1 user,  load average: 2.56, 1.60, 0.65
> Tasks:  84 total,   3 running,  81 sleeping,   0 stopped,   0 zombie
> Cpu(s): 49.7%us,  0.3%sy, 49.7%ni,  0.0%id,  0.0%wa,  0.3%hi,  0.0%si,  0.0%st
> Mem:   1036180k total,   322876k used,   713304k free,    13164k buffers
> Swap:   997880k total,        0k used,   997880k free,   149208k cached
> 
>   PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
>  6070 dnetc     39  19   664  348  264 R 49.7  0.0   1:09.71 dnetc
>  6676 tfoerste  20   0  1796  488  428 R 49.3  0.0   0:02.72 factor
> 
> Stopping dnetc gives:
> 
> top - 16:02:36 up 4 min,  1 user,  load average: 2.50, 1.87, 0.83
> Tasks:  89 total,   3 running,  86 sleeping,   0 stopped,   0 zombie
> Cpu(s): 99.3%us,  0.7%sy,  0.0%ni,  0.0%id,  0.0%wa,  0.0%hi,  0.0%si,  0.0%st
> Mem:   1036180k total,   378760k used,   657420k free,    14736k buffers
> Swap:   997880k total,        0k used,   997880k free,   180868k cached
> 
>   PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
>  6766 tfoerste  20   0  1796  488  428 R 84.9  0.0   0:05.41 factor

Thanks for this respone. This confirms that cpu's idle time is close to
zero, as I intended to verify.

> > If I am not mistaken, cpu ondemand gov goes by the cpu idle time stats,
> > which should not be affected by FAIR_GROUP_SCHED. I will lookaround for
> > other possible causes.

On further examination, ondemand governor seems to have a tunable to
ignore nice load. In your case, I see that dnetc is running at a
positive nice value (19) which could explain why ondemand gov thinks
that the cpu is only ~50% loaded.

Can you check what is the setting of this knob in your case?

# cat /sys/devices/system/cpu/cpu0/cpufreq/ondemand/ignore_nice_load

You can set that to 0 to ask ondemand gov to include nice load into
account while calculating cpu freq changes:

# echo 0 > /sys/devices/system/cpu/cpu0/cpufreq/ondemand/ignore_nice_load

This should restore the behavior of ondemand governor as seen in 2.6.23
in your case (even with CONFIG_FAIR_GROUP_SCHED enabled). Can you pls confirm 
if that happens?

> As I stated our in http://lkml.org/lkml/2008/1/26/207 the issue is solved
> after unselecting FAIR_GROUP_SCHED. 

I understand, but we want to keep CONFIG_FAIR_GROUP_SCHED enabled by
default.

Ingo,
	Most folks seem to be used to a global nice-domain, where a nice 19 
task gives up cpu in competetion to a nice-0 task (irrespective of which 
userid's they belong to). CONFIG_FAIR_USER_SCHED brings noticeable changes wrt 
that. We could possibly let it be as it is (since that is what a server
admin may possibly want when managing university servers) or modify it to be 
aware of nice-level (priority of user-sched entity is equivalent to highest 
prio task it has).

In any case, I will send across a patch to turn off CONFIG_FAIR_USER_SCHED by 
default (and instead turn on CONFIG_FAIR_CGROUP_SCHED by default).

-- 
Regards,
vatsa

  reply	other threads:[~2008-01-27 16:41 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-01-26 17:11 (ondemand) CPU governor regression between 2.6.23 and 2.6.24 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 [this message]
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
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=20080127165400.GB1044@linux.vnet.ibm.com \
    --to=vatsa@linux.vnet.ibm.com \
    --cc=Toralf.=?iso-8859-1?Q?F=F6rster_=3Ctoralf=2Efoerster=40gmx=2Ede=3E?=@snowy.in.ibm.com \
    --cc=a.p.zijlstra@chello.nl \
    --cc=dhaval@linux.vnet.ibm.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mangoo@wpkg.org \
    --cc=mingo@elte.hu \
    /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