Re: [patch 07/16] sched: expire invalid runtime

Hidetoshi Seto
2011-06-22T09:39:19Z

(2011/06/21 16:16), Paul Turner wrote:
> Since quota is managed using a global state but consumed on a per-cpu basis
> we need to ensure that our per-cpu state is appropriately synchronized.
> Most importantly, runtime that is state (from a previous period) should not be
> locally consumable.
>
> We take advantage of existing sched_clock synchronization about the jiffy to
> efficiently detect whether we have (globally) crossed a quota boundary above.
>
> One catch is that the direction of spread on sched_clock is undefined,
> specifically, we don't know whether our local clock is behind or ahead
> of the one responsible for the current expiration time.
>
> Fortunately we can differentiate these by considering whether the
> global deadline has advanced. If it has not, then we assume our clock to be
> "fast" and advance our local expiration; otherwise, we know the deadline has
> truly passed and we expire our local runtime.
>
> Signed-off-by: Paul Turner <pjt@google.com>
> Reviewed-by: Hidetoshi Seto <seto.hidetoshi@jp.fujitsu.com>
>
> ---

Reviewed-by: Hidetoshi Seto <seto.hidetoshi@jp.fujitsu.com>

Thanks,
H.Seto