From: Jonathan Nieder <jrnieder@gmail.com>
To: Doug Smythies <dsmythies@telus.net>
Cc: "'Anders Boström'" <anders@netinsight.net>,
linux-kernel@vger.kernel.org,
"'Lesław Kopeć'" <leslaw.kopec@nasza-klasa.pl>,
"'Aman Gupta'" <aman@tmm1.net>,
"'Peter Zijlstra'" <a.p.zijlstra@chello.nl>,
"'Thomas Gleixner'" <tglx@linutronix.de>,
"Charles Wang" <muming.wq@gmail.com>
Subject: Re: [3.2.16 -> 3.2.17 regression] High reported CPU load when idle
Date: Sun, 10 Jun 2012 12:49:39 -0500 [thread overview]
Message-ID: <20120610174939.GA456@burratino> (raw)
In-Reply-To: <000c01cd3e70$b651dd10$22f59730$@net>
Hi Doug et al,
Doug Smythies wrote:
> "does 556061b00c9f ("sched/nohz: Fix rq->cpu_load[] calculations",
> 2012-05-11) change anything?"
>
> I back edited those changes into my test environment yesterday. It
> made no difference with respect to this issue. (minimally tested.)
[...]
> By the way, I found and tested 5aaa0b7a2ed5b12692c9ffb5222182bd558d3146
> It is similar (minimally tested).
>
> I am certainly not an expert, and I find the load average area of the
> code extremely difficult to follow and understand. That being said, I
> think the root issue here is the 10 tick grace period. I think that
> cpu idle enter exit transitions can not be ignored during this period,
> and somehow needs to be accumulated towards the next sample time. So far,
> I have been unsuccessful trying to help with a suggested solution. I will
> continue to try.
Another load average related patch is being discussed (not meant
particularly to address the too-low load case, just mentioning it
FYI):
sched: Folding nohz load accounting more accurate
After patch 453494c3d4 (sched: Fix nohz load accounting -- again!), we can fold
the idle into calc_load_tasks_idle between the last cpu load calculating and
calc_global_load calling. However problem still exits between the first cpu
load calculating and the last cpu load calculating. Every time when we do load
calculating, calc_load_tasks_idle will be added into calc_load_tasks, even if
the idle load is caused by calculated cpus. This problem is also described in
the following link:
https://lkml.org/lkml/2012/5/24/419
This bug can be found in our work load. The average running processes number
is about 15, but the load only shows about 4.
>From [*].
Hope that helps,
Jonathan
[*] http://thread.gmane.org/gmane.linux.kernel/1310462
next prev parent reply other threads:[~2012-06-10 17:49 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20120523.144057.899060240318474097.anders@netinsight.net>
2012-05-23 21:53 ` [3.2.16 -> 3.2.17 regression] High reported CPU load when idle Jonathan Nieder
2012-05-24 21:45 ` Jonathan Nieder
2012-05-30 14:30 ` Doug Smythies
2012-05-30 14:54 ` Anders Boström
2012-06-05 15:35 ` Lesław Kopeć
2012-06-08 17:01 ` Doug Smythies
2012-06-10 17:49 ` Jonathan Nieder [this message]
2012-06-12 6:12 ` Doug Smythies
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=20120610174939.GA456@burratino \
--to=jrnieder@gmail.com \
--cc=a.p.zijlstra@chello.nl \
--cc=aman@tmm1.net \
--cc=anders@netinsight.net \
--cc=dsmythies@telus.net \
--cc=leslaw.kopec@nasza-klasa.pl \
--cc=linux-kernel@vger.kernel.org \
--cc=muming.wq@gmail.com \
--cc=tglx@linutronix.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 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.