linux-kernel - Re: [PATCH 1/4] sched: Don't account tickless CPU load on tick

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20160129095016.GZ6356@twins.programming.kicks-ass.net>
Date:	Fri, 29 Jan 2016 10:50:16 +0100
From:	Peter Zijlstra <peterz@...radead.org>
To:	Frederic Weisbecker <fweisbec@...il.com>
Cc:	Byungchul Park <byungchul.park@....com>,
	LKML <linux-kernel@...r.kernel.org>,
	Chris Metcalf <cmetcalf@...hip.com>,
	Thomas Gleixner <tglx@...utronix.de>,
	Luiz Capitulino <lcapitulino@...hat.com>,
	Christoph Lameter <cl@...ux.com>,
	"Paul E . McKenney" <paulmck@...ux.vnet.ibm.com>,
	Mike Galbraith <efault@....de>, Rik van Riel <riel@...hat.com>
Subject: Re: [PATCH 1/4] sched: Don't account tickless CPU load on tick

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.

> _ 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.

> _ 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.

> _ 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.

> _ 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.

> _ 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
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
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.