Messages in this thread | | | Date | Mon, 12 Jun 2023 14:29:25 +0200 (CEST) | From | Anna-Maria Behnsen <> | Subject | Re: [PATCH v7 19/21] timer: Implement the hierarchical pull model |
| |
On Wed, 7 Jun 2023, Frederic Weisbecker wrote:
> 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? >
Right. It will never stop the propagation - but the condition could be fulfilled when call site is tmigr_inactive_up(). My proposal for expanding the comment is the following:
/* * Walking the hierarchy is required in any case when a * remote expiry was done before. This ensures to not lose * already queued events in non active groups (see section * "Required event and timerqueue update after remote * expiry" in documentation at the top). * * The two call sites which are executed without a remote expiry * before, are not prevented from propagating changes through * the hierarchy by the return: * - When entering this path by tmigr_new_timer(), evt->ignore * is never set. * - tmigr_inactive_up() takes care of propagation by itself * and ignores return value. But an immediate return is * required because nothing has to be done in this level as * event could be ignored. */
Thanks,
Anna-Maria
| |