Re: [PATCH v7 19/21] timer: Implement the hierarchical pull model

Frederic Weisbecker
2023-06-07T13:54:26Z

Le Wed, May 24, 2023 at 09:06:27AM +0200, Anna-Maria Behnsen a écrit :
> +/*
> + * Returns true, if there is nothing to be propagated to the next level
> + *
> + * @data->nextexp is reset to KTIME_MAX; it is reused for first global
> + * event which needs to be handled by migrator (in toplevel group)
> + *
> + * This is the only place where group event expiry value is set.
> + */
> +static bool tmigr_update_events(struct tmigr_group *group,
> + struct tmigr_group *child,
> + struct tmigr_walk *data)
> +{
> + struct tmigr_event *evt, *first_childevt;
> + bool walk_done, remote = data->remote;
> + u64 nextexp;
> +
> + if (child) {
> + if (data->childstate.active)
> + return true;
> +
> + raw_spin_lock(&child->lock);
> + raw_spin_lock_nested(&group->lock, SINGLE_DEPTH_NESTING);
> +
> + first_childevt = tmigr_next_groupevt(child);
> + nextexp = child->next_expiry;
> + evt = &child->groupevt;
> + } else {
> + nextexp = data->nextexp;
> +
> + /*
> + * Set @data->nextexp to KTIME_MAX; it is reused for first
> + * global event which needs to be handled by migrator (in
> + * toplevel group)
> + */
> + data->nextexp = KTIME_MAX;
> +
> + first_childevt = evt = data->evt;
> +
> + /*
> + * Walking the hierarchy is required in any case, when a
> + * remote expiry was done before.

You can probably remove that comma because it feels like breaking the condition link.

> + * This ensures to not lost

lose

> + * already queued events in non active groups (see section
> + * "Required event and timerqueue update after remote
> + * expiry" in documentation at the top).
> + */
> + if (evt->ignore && !remote)

It looks like in the case of !remote, this branch will never end up
stopping the propagation up because either:

* We come here from tmigr_inactive_up() which takes care of the propagation.

or

* We come here from tmigr_new_timer() and ->ignore can't be set.

If I'm right, can we add a comment about that so that the poor reviewer
doesn't stutter on that for too long?

Thanks.

> + return true;