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
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
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
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
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
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
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
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
> >
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
> >
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)
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
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
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
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.
>
> 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
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
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
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..
>
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
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
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
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
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
23 matches
Mail list logo