linux-kernel - Re: [RFC] sched_clock: Track monotonic raw clock

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: <1406045843.25343.71.camel@hornet>
Date:	Tue, 22 Jul 2014 17:17:23 +0100
From:	Pawel Moll <pawel.moll@....com>
To:	Peter Zijlstra <peterz@...radead.org>
Cc:	John Stultz <john.stultz@...aro.org>,
	Steven Rostedt <rostedt@...dmis.org>,
	Ingo Molnar <mingo@...hat.com>,
	Oleg Nesterov <oleg@...hat.com>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Mel Gorman <mgorman@...e.de>,
	Andy Lutomirski <luto@...capital.net>,
	Stephen Boyd <sboyd@...eaurora.org>,
	Baruch Siach <baruch@...s.co.il>,
	Thomas Gleixner <tglx@...utronix.de>,
	lkml <linux-kernel@...r.kernel.org>
Subject: Re: [RFC] sched_clock: Track monotonic raw clock

On Fri, 2014-07-18 at 23:41 +0100, Peter Zijlstra wrote:
> So something that might be usable for all of us would be the
> 'abstracted' control loop.
> 
> So the problem is, given a Set Point (CLOCK_MONOTONIC_RAW), a Process
> Variable (sched_clock) compute a Control Output (multiplier).
> 
> If that were implemented with an interface like:
> 
> 
> struct sched_clock_cl; /* Control Loop state */
> 
> /**
>  * sched_clock_cl_init - intialize the control loop
>  */
> extern void sched_clock_cl_init(struct sched_clock_cl *sccl, u32 mult, u32 shift);
> 
> /**
>  * sched_clock_cl_update - compute a new multiplier for sched_clock
>  * @sccl - pointer to control loop state structure
>  * @sp - current set-point, aka. CLOCK_MONOTONIC_RAW
>  * @pv - current process-variable, aka. sched_clock()
>  */
> extern u32 sched_clock_cl_update(struct sched_clock_cl *sccl, u64 sp, u64 pv);

Yeah, happy to provide this.

> That way I can run one per-cpu and try and keep each individual CPU
> synced up to CLOCK_MONOTONIC_RAW, thereby also providing some inter-cpu
> guarantee (due to max error bounds on the control loop, etc..).
> 
> And you can run a single instance for the generic sched_clock code,
> since that's globally consistent.
> 
> And we'd all still be using the same control loop logic.
> 
> Now, I already mentioned max error bounds, and I've not yet looked at
> your actual control loop, but that is something to keep in mind, we want
> something that's limited.

Indeed. Richard has already expressed concerns that my coefficients
won't work everywhere (as in with different clock rate ratios) and he's
most likely right. My money is on a more advanced, "self-tuning"
solution, where we definitely need an escape condition.

> If we can do this (and I'm fairly sure we can) we can in fact kill some
> rather ugly code.

I'm really glad we're more or less on the same page. Will do some more
research in different conditions. Of course all ideas and suggestions
are more than welcome!

Pawel

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/