All of lore.kernel.org
 help / color / mirror / Atom feed
From: Dimitri Sivanich <sivanich@sgi.com>
To: Thomas Gleixner <tglx@linutronix.de>
Cc: LKML <linux-kernel@vger.kernel.org>,
	Andrew Morton <akpm@linux-foundation.org>,
	Ingo Molnar <mingo@elte.hu>, john stultz <johnstul@us.ibm.com>,
	Peter Zijlstra <peterz@infradead.org>
Subject: Re: [PATCH v2] Move calc_load call out from xtime_lock protection
Date: Sat, 11 Apr 2009 12:15:04 -0500	[thread overview]
Message-ID: <20090411171504.GA4132@sgi.com> (raw)
In-Reply-To: <alpine.LFD.2.00.0904111849450.21577@localhost.localdomain>

On Sat, Apr 11, 2009 at 06:53:45PM +0200, Thomas Gleixner wrote:
> On Sat, 11 Apr 2009, Dimitri Sivanich wrote:
> 
> > On Sat, Apr 11, 2009 at 11:51:36AM +0200, Thomas Gleixner wrote:
> > > On Fri, 10 Apr 2009, Dimitri Sivanich wrote:
> > > 
> > > > The xtime_lock is being held for long periods on larger systems due
> > > > to an extensive amount of time being spent in calc_load(),
> > > > specifically here:
> > > >   do_timer->update_times->calc_load->count_active_tasks->nr_active()
> > > > 
> > > > On a 64 cpu system I've seen this take approximately 55 usec.
> > > > Presumably it would be worse on larger systems.  This causes other
> > > > cpus to be held off in places such as
> > > > scheduler_tick->sched_clock_tick waiting for the xtime_lock to be
> > > > released.
> > > 
> > > I thought more about that. Why don't we move the calc_load() call into
> > > the timer softirq context and avoid fiddling with all the call sites ?
> > > Also moving calc_load out of the timer interrupt context reduces the
> > > interrupts off section as well.
> > > 
> > Sounds reasonable to me.
> 
> Ok. I looked once more and I wonder if it's possible to avoid the
> whole for_each_online_cpu() business by moving the accounting into the
> scheduler and be a bit more clever than just blindly running over all
> cpus everytime. 
> 
> /me goes back to stare a bit more at the avenrun stuff
> 

Also, if my patch gets replaced by this, you might want to avoid saving intermediate results in calc_load, as my patch attempts to do.

  reply	other threads:[~2009-04-11 17:15 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-04-10 17:34 [PATCH v2] Move calc_load call out from xtime_lock protection Dimitri Sivanich
2009-04-11  9:51 ` Thomas Gleixner
2009-04-11 16:24   ` Dimitri Sivanich
2009-04-11 16:53     ` Thomas Gleixner
2009-04-11 17:15       ` Dimitri Sivanich [this message]
2009-04-11 18:57         ` Thomas Gleixner

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=20090411171504.GA4132@sgi.com \
    --to=sivanich@sgi.com \
    --cc=akpm@linux-foundation.org \
    --cc=johnstul@us.ibm.com \
    --cc=linux-kernel@vger.kernel.org \
    --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 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.