Re: [RFC] sched_clock: Track monotonic raw clock

From: Pawel Moll
Date: Tue Jul 22 2014 - 12:17:28 EST


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@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/