Re: [PATCH review for 4.4 12/47] clk: wm831x: fix usleep_range with bad range

From: Charles Keepax
Date: Fri Oct 06 2017 - 06:01:33 EST

On Fri, Oct 06, 2017 at 08:03:23AM +0000, Nicholas Mc Guire wrote:
> On Sun, Sep 24, 2017 at 12:18:12AM +0000, Levin, Alexander (Sasha Levin) wrote:
> > On Fri, Sep 22, 2017 at 09:46:28AM +0100, Charles Keepax wrote:
> > >On Wed, Sep 20, 2017 at 04:45:02AM +0000, Levin, Alexander (Sasha Levin) wrote:
> > >Does this patch really make sense for stable, isn't this really
> > >just a small optimisation? The patch is pretty harmless so I
> > >can't see applying it causing any problems, just curious what
> > >problems not having it is causing.
> >
> > Looking back at this, I think I misunderstood a scenario in the scheduler this might be causing. What you say makes sense, I'll drop it.
> >
> sorry for the delay - was off-line.
> The motivation is that if usleep_range is used with min==max
> then it allows no consolidation of highresolution timers at all
> but as this is not an atomic code-section anyway it is not sensible
> to force a precise timer - the pach relaxes the timing so that
> the highrestimers load can be reduced.
> Technically this should have no effect at all as the jitter of
> the system is probably a lot higher than the range given anyway
> but the range allows optimization of highresolution timers.

Indeed, which is why it is a good commit that was merged into

> So basically you are right its an optimization only but it is not
> only relevant to keep the highrestimers well optimized it is also
> the recommendation in the kernel documentation and since there is
> not drawback with this optimization I think it should be considered even
> if it is not important.

But my understanding is only patches to fix significant issues
should be backported to stable, this doesn't really do that. As
you say it is fairly harmless though, so I can't see it causing
any problems so I am certainly not nak-ing it.