Re: Future of NOHZ full/isolation development (was Re: [NOHZ] Remove scheduler_tick_max_deferment)

2014-11-12 Thread Viresh Kumar
On 12 November 2014 20:46, Viresh Kumar wrote: > On 12 November 2014 20:36, Peter Zijlstra wrote: >> I don't think you need to add anything. We already have tracepoints for >> every single interrupt (and therefore also for the hrtimer one) and we >> have expiry tracepoints. > > I will crosscheck

Re: Future of NOHZ full/isolation development (was Re: [NOHZ] Remove scheduler_tick_max_deferment)

2014-11-12 Thread Viresh Kumar
On 12 November 2014 20:36, Peter Zijlstra wrote: > I don't think you need to add anything. We already have tracepoints for > every single interrupt (and therefore also for the hrtimer one) and we > have expiry tracepoints. I will crosscheck this again but as far as I remember these spurious inter

Re: Future of NOHZ full/isolation development (was Re: [NOHZ] Remove scheduler_tick_max_deferment)

2014-11-12 Thread Peter Zijlstra
On Wed, Nov 12, 2014 at 08:26:05PM +0530, Viresh Kumar wrote: > On 12 November 2014 19:24, Frederic Weisbecker wrote: > > I'd rather leave that to tracepoints. Like trace_hrtimer_spurious(). > > Yeah, it was just to prove things right on the console without getting > into traces. > > > Or better

Re: Future of NOHZ full/isolation development (was Re: [NOHZ] Remove scheduler_tick_max_deferment)

2014-11-12 Thread Viresh Kumar
On 12 November 2014 19:24, Frederic Weisbecker wrote: > I'd rather leave that to tracepoints. Like trace_hrtimer_spurious(). Yeah, it was just to prove things right on the console without getting into traces. > Or better yet: have trace_hrtimer_interrupt() which we can compare against > trace_hr

Re: Future of NOHZ full/isolation development (was Re: [NOHZ] Remove scheduler_tick_max_deferment)

2014-11-12 Thread Frederic Weisbecker
On Wed, Nov 12, 2014 at 11:41:09AM +0530, Viresh Kumar wrote: > On 11 November 2014 22:45, Frederic Weisbecker wrote: > > > Here is a summarized list: > > > > * Unbound workqueues affinity (to housekeeper) > > * Unbound timers affinity (to housekeeper) > > * 1 Hz residual scheduler tick offlining

Re: Future of NOHZ full/isolation development (was Re: [NOHZ] Remove scheduler_tick_max_deferment)

2014-11-11 Thread Viresh Kumar
On 11 November 2014 22:45, Frederic Weisbecker wrote: > Here is a summarized list: > > * Unbound workqueues affinity (to housekeeper) > * Unbound timers affinity (to housekeeper) > * 1 Hz residual scheduler tick offlining to housekeeper > * Fix some scheduler accounting that don't even work with

Re: Future of NOHZ full/isolation development (was Re: [NOHZ] Remove scheduler_tick_max_deferment)

2014-11-11 Thread Christoph Lameter
On Tue, 11 Nov 2014, Paul E. McKenney wrote: > I guess I should have remembered that before suggesting this to Christoph, > my apologies to all! No this is good. Do not worry. I can just throw out the one or other patch to ensure that the discussion continues and then we can figure out how to com

Re: Future of NOHZ full/isolation development (was Re: [NOHZ] Remove scheduler_tick_max_deferment)

2014-11-11 Thread Paul E. McKenney
On Tue, Nov 11, 2014 at 06:15:28PM +0100, Frederic Weisbecker wrote: > On Mon, Nov 10, 2014 at 12:26:51PM -0600, Christoph Lameter wrote: > > > > > > Would it make sense for unlimited max deferment to be available as > > > a boot parameter? That would allow people who want tick-free execution > >

Future of NOHZ full/isolation development (was Re: [NOHZ] Remove scheduler_tick_max_deferment)

2014-11-11 Thread Frederic Weisbecker
On Mon, Nov 10, 2014 at 12:26:51PM -0600, Christoph Lameter wrote: > > > > Would it make sense for unlimited max deferment to be available as > > a boot parameter? That would allow people who want tick-free execution > > more than accurate stats to get that easily, while keeping stats accurate > >

Re: [NOHZ] Remove scheduler_tick_max_deferment

2014-11-11 Thread Christoph Lameter
On Tue, 11 Nov 2014, Frederic Weisbecker wrote: > "there" here is the syscall/exception/interrupt entry path. And like I said, > updating > timekeeping from these places is overkill (although we do it in interrupt > entry on > dynticks-idle, but we don't have timekeeping when all system is idle)

Re: [NOHZ] Remove scheduler_tick_max_deferment

2014-11-11 Thread Frederic Weisbecker
On Tue, Nov 11, 2014 at 08:58:35AM -0600, Christoph Lameter wrote: > On Mon, 10 Nov 2014, Frederic Weisbecker wrote: > > > Ok, I confess we moved part of that housekeeping to the > > syscall/exception/interrupt > > entry path. We did that for cputime accounting and RCU. And it's possible to > > e

Re: [NOHZ] Remove scheduler_tick_max_deferment

2014-11-11 Thread Christoph Lameter
On Mon, 10 Nov 2014, Frederic Weisbecker wrote: > Ok, I confess we moved part of that housekeeping to the > syscall/exception/interrupt > entry path. We did that for cputime accounting and RCU. And it's possible to > even do that for timekeeping. But then the kernel entrypoint is going to be > e

Re: [NOHZ] Remove scheduler_tick_max_deferment

2014-11-10 Thread Frederic Weisbecker
On Thu, Nov 06, 2014 at 11:24:59AM -0600, Christoph Lameter wrote: > I thought there is already logic in there to compensate for times when the > tick is off. > > tick_do_update_jiffies64 calculates the time differential and calculates > the number of ticks from there calling do_timer() with the n

Re: [NOHZ] Remove scheduler_tick_max_deferment

2014-11-10 Thread Frederic Weisbecker
On Sat, Nov 01, 2014 at 04:52:13PM -0500, Christoph Lameter wrote: > On Sat, 1 Nov 2014, Thomas Gleixner wrote: > > > On Fri, 31 Oct 2014, Christoph Lameter wrote: > > > The reasoning behind this function is not clear to me and removal seems > > > > The comment above the function is clear enough.

Re: [NOHZ] Remove scheduler_tick_max_deferment

2014-11-10 Thread Christoph Lameter
> > Would it make sense for unlimited max deferment to be available as > a boot parameter? That would allow people who want tick-free execution > more than accurate stats to get that easily, while keeping stats accurate > for everyone else. Subject: Make the maximum tick deferral for CONFIG_NO_HZ

Re: [NOHZ] Remove scheduler_tick_max_deferment

2014-11-10 Thread Christoph Lameter
On Mon, 10 Nov 2014, Paul E. McKenney wrote: > Would it make sense for unlimited max deferment to be available as > a boot parameter? That would allow people who want tick-free execution > more than accurate stats to get that easily, while keeping stats accurate > for everyone else. Well at leas

Re: [NOHZ] Remove scheduler_tick_max_deferment

2014-11-10 Thread Christoph Lameter
On Mon, 10 Nov 2014, Viresh Kumar wrote: > On 6 November 2014 22:54, Christoph Lameter wrote: > > > We did not need to housekeeper in the dynticks idle case. What is so > > different about dynticks busy? > > We do have a running task here and so the stats are important.. The task is running in u

Re: [NOHZ] Remove scheduler_tick_max_deferment

2014-11-10 Thread Paul E. McKenney
On Mon, Nov 10, 2014 at 12:41:38PM +0530, Viresh Kumar wrote: > On 6 November 2014 22:54, Christoph Lameter wrote: > > > We did not need to housekeeper in the dynticks idle case. What is so > > different about dynticks busy? > > We do have a running task here and so the stats are important.. >

Re: [NOHZ] Remove scheduler_tick_max_deferment

2014-11-09 Thread Viresh Kumar
On 6 November 2014 22:54, Christoph Lameter wrote: > We did not need to housekeeper in the dynticks idle case. What is so > different about dynticks busy? We do have a running task here and so the stats are important.. > I may not have the complete picture of the timer tick processing in my > m

Re: [NOHZ] Remove scheduler_tick_max_deferment

2014-11-06 Thread Christoph Lameter
On Sat, 1 Nov 2014, Thomas Gleixner wrote: > * balancing, etc... continue to move forward, even > * with a very low granularity. > > So this talks about the scheduler tick obviously, right? Obviously. > Now scheduler_tick() is invoked from update_process_times() and > update_process_times() is

Re: [NOHZ] Remove scheduler_tick_max_deferment

2014-11-01 Thread Thomas Gleixner
On Sat, 1 Nov 2014, Christoph Lameter wrote: > On Sat, 1 Nov 2014, Thomas Gleixner wrote: > > > On Fri, 31 Oct 2014, Christoph Lameter wrote: > > > The reasoning behind this function is not clear to me and removal seems > > > > The comment above the function is clear enough. > > I looked around i

Re: [NOHZ] Remove scheduler_tick_max_deferment

2014-11-01 Thread Christoph Lameter
On Sat, 1 Nov 2014, Thomas Gleixner wrote: > On Fri, 31 Oct 2014, Christoph Lameter wrote: > > The reasoning behind this function is not clear to me and removal seems > > The comment above the function is clear enough. I looked around into the functions called by the timer interrupt for accountin

Re: [NOHZ] Remove scheduler_tick_max_deferment

2014-11-01 Thread Thomas Gleixner
On Fri, 31 Oct 2014, Christoph Lameter wrote: > The reasoning behind this function is not clear to me and removal seems The comment above the function is clear enough. > to have a limited impact on the system overall. Even without the > cap to 1 second the system will be limited by the boundaries