From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753618AbbJPHMJ (ORCPT ); Fri, 16 Oct 2015 03:12:09 -0400 Received: from mail-lb0-f173.google.com ([209.85.217.173]:33013 "EHLO mail-lb0-f173.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753550AbbJPHMH (ORCPT ); Fri, 16 Oct 2015 03:12:07 -0400 Date: Fri, 16 Oct 2015 09:12:02 +0200 From: Ingo Molnar To: Jason Low Cc: Jason Low , Peter Zijlstra , Thomas Gleixner , linux-kernel@vger.kernel.org, Oleg Nesterov , "Paul E. McKenney" , Frederic Weisbecker , Davidlohr Bueso , Steven Rostedt , Andrew Morton , George Spelvin , hideaki.kimura@hpe.com, terry.rudd@hpe.com, scott.norton@hpe.com Subject: Re: [PATCH v2 0/4] timer: Improve itimers scalability Message-ID: <20151016071202.GA20129@gmail.com> References: <1444849677-29330-1-git-send-email-jason.low2@hp.com> <20151015084702.GA16953@gmail.com> <1444935676.29506.15.camel@j-VirtualBox> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1444935676.29506.15.camel@j-VirtualBox> User-Agent: Mutt/1.5.23 (2014-03-12) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org * Jason Low wrote: > > > With this patch set (along with commit 1018016c706f mentioned above), > > > the performance hit of itimers almost completely goes away on the > > > 16 socket system. > > > > > > Jason Low (4): > > > timer: Optimize fastpath_timer_check() > > > timer: Check thread timers only when there are active thread timers > > > timer: Convert cputimer->running to bool > > > timer: Reduce unnecessary sighand lock contention > > > > > > include/linux/init_task.h | 3 +- > > > include/linux/sched.h | 9 ++++-- > > > kernel/fork.c | 2 +- > > > kernel/time/posix-cpu-timers.c | 63 ++++++++++++++++++++++++++++----------- > > > 4 files changed, 54 insertions(+), 23 deletions(-) > > > > Is there some itimers benchmark that can be used to measure the effects of these > > changes? > > Yes, we also wrote a micro benchmark which generates cache misses and measures > the average cost of each cache miss (with itimers enabled). We used this while > writing and testing patches, since it takes a bit longer to set up and run the > database. Mind posting it, so that people can stick it into a new 'perf bench timer' subcommand, and/or reproduce your results with it? Thanks, Ingo