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: <20160201100513.GD29804@X58A-UD3R>
Date:	Mon, 1 Feb 2016 19:05:13 +0900
From:	Byungchul Park <byungchul.park@....com>
To:	Peter Zijlstra <peterz@...radead.org>
Cc:	Frederic Weisbecker <fweisbec@...il.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 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!