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