public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Mike Galbraith <umgwanakikbuti@gmail.com>
To: Libo Chen <libo.chen@huawei.com>
Cc: tglx@linutronix.de, mingo@elte.hu,
	LKML <linux-kernel@vger.kernel.org>,
	Greg KH <gregkh@linuxfoundation.org>,
	Li Zefan <lizefan@huawei.com>,
	peterz@infradead.org
Subject: Re: balance storm
Date: Tue, 27 May 2014 11:55:53 +0200	[thread overview]
Message-ID: <1401184553.5134.115.camel@marge.simpson.net> (raw)
In-Reply-To: <53844510.1040502@huawei.com>

On Tue, 2014-05-27 at 15:56 +0800, Libo Chen wrote: 
> On 2014/5/26 22:19, Mike Galbraith wrote:
> > On Mon, 2014-05-26 at 20:16 +0800, Libo Chen wrote: 
> >> On 2014/5/26 13:11, Mike Galbraith wrote:
> > 
> >>> Your synthetic test is the absolute worst case scenario.  There has to
> >>> be work between wakeups for select_idle_sibling() to have any chance
> >>> whatsoever of turning in a win.  At 0 work, it becomes 100% overhead.
> >>
> >> not synthetic, it is a real problem in our product. under no load, waste
> >> much cpu time.
> > 
> > What happens in your product if you apply the commit I pointed out?
> 
> under no load, cpu usage is up to 60%, but the same apps cost 10% on
> susp sp1.  The apps use a lot of timer.

Something is rotten.  3.14-rt contains that commit, I ran your test with
256 threads on 64 core box, saw ~4%.

Putting master/nopreempt config on box and doing the same test, box is
chewing up truckloads of CPU, but not from migrations. 

perf top -g --sort=symbol

Samples: 7M of event 'cycles', Event count (approx.): 1316249172581                                                                                                                                                                         
-   82.56%  [k] _raw_spin_lock_irqsave                                                                                                                                                                                                     ▒
   - _raw_spin_lock_irqsave                                                                                                                                                                                                                ▒
      - 96.59% __nanosleep_nocancel                                                                                                                                                                                                        ◆
           100.00% __libc_start_main                                                                                                                                                                                                       ▒
        2.88% __poll                                                                                                                                                                                                                       ▒
           0                                                                                                                                                                                                                               ▒
+    1.56%  [k] native_write_msr_safe                                                                                                                                                                                                      ▒
+    1.21%  [k] update_cfs_shares                                                                                                                                                                                                          ▒
+    0.92%  [k] __schedule                                                                                                                                                                                                                 ▒
+    0.88%  [k] _raw_spin_lock                                                                                                                                                                                                             ▒
+    0.73%  [k] update_cfs_rq_blocked_load                                                                                                                                                                                                 ▒
+    0.62%  [k] idle_cpu                                                                                                                                                                                                                   ▒
+    0.47%  [.] usleep                                                                                                                                                                                                                     ▒
+    0.41%  [k] cpuidle_enter_state                                                                                                                                                                                                        ▒
+    0.37%  [k] set_task_cpu

Oh, 256 * usleep(100) is not a great idea.

	-Mike


  reply	other threads:[~2014-05-27  9:56 UTC|newest]

Thread overview: 33+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-05-26  3:04 balance storm Libo Chen
2014-05-26  5:11 ` Mike Galbraith
2014-05-26 12:16   ` Libo Chen
2014-05-26 14:19     ` Mike Galbraith
2014-05-27  7:56       ` Libo Chen
2014-05-27  9:55         ` Mike Galbraith [this message]
2014-05-27 12:50           ` Libo Chen
2014-05-27 13:20             ` Mike Galbraith
2014-05-28  1:04               ` Libo Chen
2014-05-28  1:53                 ` Mike Galbraith
2014-05-28  6:54                   ` Libo Chen
2014-05-28  8:16                     ` Mike Galbraith
2014-05-28  9:08                     ` Thomas Gleixner
2014-05-28 10:30                       ` Peter Zijlstra
2014-05-28 10:52                         ` Borislav Petkov
2014-05-28 11:43                       ` Libo Chen
2014-05-28 11:55                         ` Mike Galbraith
2014-05-29  7:58                           ` Libo Chen
2014-05-29  7:57                       ` Libo Chen
2014-05-27 20:53             ` Thomas Gleixner
2014-05-28  1:06               ` Libo Chen
2014-05-26  7:56 ` Mike Galbraith
2014-05-26 11:49   ` Libo Chen
2014-05-26 14:03     ` Mike Galbraith
2014-05-27  7:44       ` Libo Chen
2014-05-27  8:12         ` Mike Galbraith
2014-05-27  9:48     ` Peter Zijlstra
2014-05-27 10:05       ` Mike Galbraith
2014-05-27 10:43         ` Peter Zijlstra
2014-05-27 10:55           ` Mike Galbraith
2014-05-27 12:56             ` Libo Chen
2014-05-27 12:55       ` Libo Chen
2014-05-27 13:13         ` 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:
  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=1401184553.5134.115.camel@marge.simpson.net \
    --to=umgwanakikbuti@gmail.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=libo.chen@huawei.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=lizefan@huawei.com \
    --cc=mingo@elte.hu \
    --cc=peterz@infradead.org \
    --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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox