Re: [RFC] sched_clock: Track monotonic raw clock

[Peter Zijlstra]

On Fri, Jul 18, 2014 at 10:22:50PM +0200, Peter Zijlstra wrote:
> So the generic stuff seems optimized for 32bit arch, short clocks and
> seems to hard assume the clock is globally consistent.
> 
> The x86 sched_clock code is optimized for 64bit, has a full 64bit clock
> and cannot ever assume the thing is globally consistent (until Intel/AMD
> stop making the TSC register writable -- including, and maybe
> especially, for SMM).
> 
> There is just not much that overlaps there.

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);


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.

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

Attachment: pgpnFuet7bZom.pgp
Description: PGP signature