All of lore.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: 23+ 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 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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.