lkml.org 
[lkml]   [2016]   [Feb]   [1]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH 1/4] sched: Don't account tickless CPU load on tick
On Fri, Jan 29, 2016 at 10:50:16AM +0100, Peter Zijlstra wrote:
> On Thu, Jan 28, 2016 at 05:01:26PM +0100, Frederic Weisbecker wrote:
> > So lets check all the things we call on scheduler_tick():
> >
> > _ sched_clock_tick(): maybe it doesn't need to be called when idle. I'm not sure.
> > Some code in idle (timers, irqs, ...) might need to call sched_clock().
>
> Only needed if you've got a shady TSC.

Yeh.. IMO, this can be done without the tick handling during nohz, with the
patch I am attaching. Could you check the patch? Or we have to handle it
remotely, too. (for a crazy TSC)

>
> > _ update_rq_clock(), task_tick(): task_tick is empty for idle class, so we probably
> > don't need an updated rq either.
>
> Right, for regular NOHZ we'll be running the idle task, and the idle
> tick handler is empty. So for NOHZ you can ignore this.
>
> For NOHZ_FULL you'll not be running the idle task and this gets
> 'interesting'.
>
> The most important part would be tracking the task runtime, which is
> used for a number of user visible things. This should be doable
> remotely.

Isn't there any way to show it to user at the time it's requested?

>
> > _ update_cpu_load_active(): I was about to fix the issue properly and make it account
> > correctly on idle ticks but we might as well want to spare it.
>
> Right, we've gone over this one in detail in other emails I think.

Doing it remotely... hm...

>
> > _ calc_global_load_tick(): no idea
>
> Can easily be done remote. However, this only records deltas of
> nr_active (:= nr_running + nr_uninterruptible) and for NOHZ and
> NOHZ_FULL this should not change, therefore the delta _should_ be 0 and
> you can skip this.

It sounds good.

>
> > _ perf_event_task_tick(): needed, some freq CPU events can trigger in idle and need
> > adjustments
>
> Right, this is a tricky one. Maybe I should look into moving this into a
> hrtimer, but that too has 'fun' problems IIRC. I'll put it on the TODO
> list somewhere.

Good luck. I'm sure you'll do well.

>
> > _ trigger_load_balance(): maybe needed, I see it triggers the softirq after some
> > rebalance delay, regardless of the current CPU idleness.
>
> We already have NOHZ remote balancing, we could (and should) probably do

I think so.

> the same for NOHZ_FULL. Then again, I would expect the NOHZ_FULL cpus to
> not actually be part of a balance domain, so we could probably detect

Could not the NOHZ_FULL cpus be part of a balance domain? It sounds good.

> and short-circuit this.
>
> > _ rq_last_tick_reset(): not needed in idle
>
> Right, part of the NOHZ_FULL 'hack', once you fix all the remote
> accounting stuff this could go away entirely think.

I'm sure it can be removed eventually!

\
 
 \ /
  Last update: 2016-02-01 11:21    [W:0.096 / U:0.152 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site