All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jason Low <jason.low2@hp.com>
To: Davidlohr Bueso <dave@stgolabs.net>
Cc: Linus Torvalds <torvalds@linux-foundation.org>,
	Peter Zijlstra <peterz@infradead.org>,
	Ingo Molnar <mingo@kernel.org>,
	Thomas Gleixner <tglx@linutronix.de>,
	linux-kernel@vger.kernel.org,
	"Paul E. McKenney" <paulmck@linux.vnet.ibm.com>,
	Andrew Morton <akpm@linux-foundation.org>,
	Oleg Nesterov <oleg@redhat.com>,
	Mike Galbraith <umgwanakikbuti@gmail.com>,
	Frederic Weisbecker <fweisbec@gmail.com>,
	Mel Gorman <mgorman@suse.de>,
	Steven Rostedt <rostedt@goodmis.org>,
	Preeti U Murthy <preeti@linux.vnet.ibm.com>,
	hideaki.kimura@hp.com, Aswin Chandramouleeswaran <aswin@hp.com>,
	Scott J Norton <scott.norton@hp.com>,
	jason.low2@hp.com
Subject: Re: [PATCH 2/3] sched, timer: Use atomics for thread_group_cputimer to improve scalability
Date: Wed, 15 Apr 2015 14:15:33 -0700	[thread overview]
Message-ID: <1429132533.7039.156.camel@j-VirtualBox> (raw)
In-Reply-To: <1429107823.6795.18.camel@stgolabs.net>

On Wed, 2015-04-15 at 07:23 -0700, Davidlohr Bueso wrote:
> On Tue, 2015-04-14 at 16:09 -0700, Jason Low wrote:
> > While running a database workload, we found a scalability issue with itimers.
> > 
> > Much of the problem was caused by the thread_group_cputimer spinlock.
> > Each time we account for group system/user time, we need to obtain a
> > thread_group_cputimer's spinlock to update the timers. On larger systems
> > (such as a 16 socket machine), this caused more than 30% of total time
> > spent trying to obtain this kernel lock to update these group timer stats.
> > 
> > This patch converts the timers to 64 bit atomic variables and use
> > atomic add to update them without a lock. With this patch, the percent
> > of total time spent updating thread group cputimer timers was reduced
> > from 30% down to less than 1%. 
> 
> What does 30% less time spent dealing with the thread_group_cputimer's
> spinlock buy us? iow, does this help DB benchmark throughput or such?

Yes, this also helps increase throughput since the scalability issue
causes a performance degradation in the database workload. I currently
don't have the exact  numbers though.


  reply	other threads:[~2015-04-15 21:15 UTC|newest]

Thread overview: 34+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-04-14 23:09 [PATCH 0/3] sched, timer: Improve scalability of itimers Jason Low
2015-04-14 23:09 ` [PATCH 1/3] sched, timer: Remove usages of ACCESS_ONCE in the scheduler Jason Low
2015-04-14 23:59   ` Steven Rostedt
2015-04-15  2:12     ` Jason Low
2015-04-15  2:40       ` Steven Rostedt
2015-04-15  7:46         ` Ingo Molnar
2015-04-15 18:49           ` Jason Low
2015-04-15 19:16             ` Steven Rostedt
2015-04-16  2:46           ` Jason Low
2015-04-16 16:52           ` Peter Zijlstra
2015-04-16 18:02             ` Ingo Molnar
2015-04-16 18:15               ` Peter Zijlstra
2015-04-16 18:24                 ` Ingo Molnar
2015-04-16 19:02                   ` Peter Zijlstra
2015-04-16 19:41                     ` Paul E. McKenney
2015-04-17  3:25                   ` Jason Low
2015-04-17  8:19                     ` Ingo Molnar
2015-04-16 21:00                 ` Jason Low
2015-04-16  2:29         ` Jason Low
2015-04-16  2:37           ` Steven Rostedt
2015-04-14 23:09 ` [PATCH 2/3] sched, timer: Use atomics for thread_group_cputimer to improve scalability Jason Low
2015-04-15  7:33   ` Ingo Molnar
2015-04-15  7:35     ` Ingo Molnar
2015-04-15 17:14       ` Jason Low
2015-04-15 10:37   ` Preeti U Murthy
2015-04-15 19:09     ` Jason Low
2015-04-15 13:25   ` Frederic Weisbecker
2015-04-15 13:32     ` Peter Zijlstra
2015-04-15 20:04       ` Jason Low
2015-04-15 14:23   ` Davidlohr Bueso
2015-04-15 21:15     ` Jason Low [this message]
2015-04-14 23:09 ` [PATCH 3/3] sched, timer: Use cmpxchg to do updates in update_gt_cputime() Jason Low
2015-04-14 23:53 ` [PATCH 0/3] sched, timer: Improve scalability of itimers Linus Torvalds
2015-04-15  7:24   ` Ingo Molnar

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=1429132533.7039.156.camel@j-VirtualBox \
    --to=jason.low2@hp.com \
    --cc=akpm@linux-foundation.org \
    --cc=aswin@hp.com \
    --cc=dave@stgolabs.net \
    --cc=fweisbec@gmail.com \
    --cc=hideaki.kimura@hp.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mgorman@suse.de \
    --cc=mingo@kernel.org \
    --cc=oleg@redhat.com \
    --cc=paulmck@linux.vnet.ibm.com \
    --cc=peterz@infradead.org \
    --cc=preeti@linux.vnet.ibm.com \
    --cc=rostedt@goodmis.org \
    --cc=scott.norton@hp.com \
    --cc=tglx@linutronix.de \
    --cc=torvalds@linux-foundation.org \
    --cc=umgwanakikbuti@gmail.com \
    /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.