All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Paul E. McKenney" <paulmck@linux.vnet.ibm.com>
To: Pascal CHAPPERON <pascal.chapperon@wanadoo.fr>
Cc: Josh Boyer <jwboyer@redhat.com>,
	linux-kernel@vger.kernel.org, kernel-team@fedoraproject.org
Subject: Re: RCU related performance regression in 3.3
Date: Thu, 5 Apr 2012 07:39:18 -0700	[thread overview]
Message-ID: <20120405143918.GE27672@linux.vnet.ibm.com> (raw)
In-Reply-To: <1838583439.163624.1333635333132.JavaMail.www@wwinf1m19>

On Thu, Apr 05, 2012 at 04:15:33PM +0200, Pascal CHAPPERON wrote:
> Hello,
> 
> I didn't notice any significant slowdown while the system is up and running. A full kernel compilation (make -j 16) takes 14mn with both 3.2.10 and 3.3.0.

OK, so the natural approach is to disable CONFIG_RCU_FAST_NO_HZ at
boot time.  Unfortunately, you appear to need it to remain disabled
through at least filesystem mounting, which if I understand correctly
happens long after system_state gets set to SYSTEM_RUNNING.

If RCU has some way to find out when init is complete, I can easily
make it so that CONFIG_RCU_FAST_NO_HZ optimizes for speed during boot
and energy efficiency during runtime.

One thing I could easily do would be to provide a sysfs parameter or
some such that allows the boot process to enable energy-efficiency
mode at runtime.  I would much prefer to make this automatic, though.

Other thoughts?

							Thanx, Paul

> Pascal
> 
> 
> > Message du 05/04/12 16:01
> > De : "Paul E. McKenney" 
> > A : "Josh Boyer" 
> > Copie à : linux-kernel@vger.kernel.org, kernel-team@fedoraproject.org, pascal.chapperon@wanadoo.fr
> > Objet : Re: RCU related performance regression in 3.3
> > 
> > On Thu, Apr 05, 2012 at 08:37:59AM -0400, Josh Boyer wrote:
> > > On Wed, Apr 04, 2012 at 02:36:33PM -0700, Paul E. McKenney wrote:
> > > > On Wed, Apr 04, 2012 at 11:27:27AM -0400, Josh Boyer wrote:
> > > > > Hi Paul,
> > > > > 
> > > > > We've had a few reports of some boot slowdowns with the 3.3 rebase we
> > > > > did in Fedora 16. One of our users volunteered to bisect a vanilla
> > > > > kernel and wound up at "rcu: Permit dyntick-idle with callbacks pending
> > > > > (commit 7cb924990)". You can find more details in the bug [1], but it's
> > > > > been reported on both physical hardware and in virtual machines.
> > > > > 
> > > > > Have you seen anything like this in your testing? Given the user used a
> > > > > vanilla 3.3 kernel, I'm wondering if there is a targetted fix that might
> > > > > be backported. If so, it would be good to get that headed to the 3.3.y
> > > > > stable tree.
> > > > > 
> > > > > josh
> > > > > 
> > > > > [1] https://bugzilla.redhat.com/show_bug.cgi?id=806548
> > > > 
> > > > I will look into this. In the meantime, does setting
> > > > CONFIG_RCU_FAST_NO_HZ=n get rid of the slowdowns?
> > > 
> > > Seems so. Pascal tried 3.4-rc1 with and without that set and found that
> > > disabling it lead to consistent timings. He put his findings in the
> > > bug, and I've also now CC'd him.
> > 
> > Thank you for the info! Is the performance problem limited to boot time,
> > or are there performance problems when the system is up and running?
> > 
> > Thanx, Paul
> > 
> >
> 


  reply	other threads:[~2012-04-05 14:40 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-04-04 15:27 RCU related performance regression in 3.3 Josh Boyer
2012-04-04 21:36 ` Paul E. McKenney
2012-04-05 12:37   ` Josh Boyer
2012-04-05 14:00     ` Paul E. McKenney
2012-04-05 14:15       ` Pascal CHAPPERON
2012-04-05 14:39         ` Paul E. McKenney [this message]
2012-04-06  9:18           ` Pascal Chapperon
2012-04-10 16:07             ` Paul E. McKenney
2012-04-11 15:06               ` Pascal
2012-04-12 18:04                 ` Paul E. McKenney
2012-04-16 21:02                   ` Paul E. McKenney
2012-04-18  9:37                     ` Pascal Chapperon
2012-04-18 14:01                       ` Paul E. McKenney
2012-04-18 15:00                         ` Pascal Chapperon
2012-04-18 15:23                           ` Paul E. McKenney
2012-04-20 14:45                             ` Pascal Chapperon
  -- strict thread matches above, loose matches on Subject: below --
2012-04-27 12:15 Pascal Chapperon
2012-04-28  3:42 ` Paul E. McKenney
2012-05-01  0:02   ` Paul E. McKenney
2012-05-01  8:55     ` Pascal Chapperon
2012-05-01 15:45       ` Paul E. McKenney
2012-05-04 14:42         ` Pascal Chapperon
2012-05-04 15:04           ` Paul E. McKenney
2012-05-04 21:41             ` Pascal Chapperon
2012-05-04 23:14               ` Paul E. McKenney
2012-05-10  8:40                 ` Pascal Chapperon
2012-05-14 22:32                 ` Paul E. McKenney
2012-05-18 11:01                   ` Pascal Chapperon
2012-05-18 12:14                     ` Paul E. McKenney
2012-05-18 14:48                       ` Pascal Chapperon

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=20120405143918.GE27672@linux.vnet.ibm.com \
    --to=paulmck@linux.vnet.ibm.com \
    --cc=jwboyer@redhat.com \
    --cc=kernel-team@fedoraproject.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=pascal.chapperon@wanadoo.fr \
    /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.