Re: [RFC PATCH 1/4] timekeeping: Remove xtime_remainder from ntp_error accumulation

[John Stultz]

On Tue, May 19, 2026 at 3:20 PM David Woodhouse <dwmw2@xxxxxxxxxxxxx> wrote:
>
> On Tue, 2026-05-19 at 14:54 -0700, John Stultz wrote:
> >
> > Its a nice analogy. Though if you're going to use it in your commit
> > messages, it might be good to also add a comment to the
> > timekeeping_adjustment() logic so there is an clear anchor to the code
> > for folks who might not be as familiar with the detail.
> >
> >
> > > > Also I'm not sure its very clear what you mean by "monotonicity clawback".
> > >
> > > This is the offset applied by timekeeping_apply_adjustment() in order
> > > to ensure that the observed xtime remains monotonic when the dithering
> > > switches back from 'mult+1' to 'mult' and a consumer may have seen a
> > > 'later' time than it's about to set in {cycle_last,mult}.
> > >
> >
> > This one I find less clarifying, but I do recognize "adjustments to
> > the base xtime_nsec made when adjusting the multiplier due to
> > unaccumulated cycles" is a mouthful.
> >
> > The "xtime_nsec adjustment in timekeeping_apply_adjustment()" is
> > probably easier/clearer?
>
> How's this...
>
> # Linux Timekeeping: Tick-Based Clock Discipline

So, I'm guessing given how fast you were to create this and how
verbose it is, it was AI generated? (Apologies if I'm wrong here!)

If so, do remember to use the Assisted-by tag.

I'll try to find some time to carefully review it, but while I
appreciate the benefit of having a tool help write this, I'm not super
excited about externalizing the cost of the review onto others.
As careful review and feedback of an individuals work feels like
investing in that collaborative effort, but doing the same for AI
generated output just feels like a chore.

Though I also understand a similar frustration of having maintainers
gatekeeping their approval by asking for more (cleanups, docs, etc)
labor - so it's probably a fair turnabout.
But I've got to play the part here. :)

thanks
-john