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

[Charles Keepax]

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
mainline.

> 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.

Thanks,
Charles