From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751567AbdJFKB2 (ORCPT ); Fri, 6 Oct 2017 06:01:28 -0400 Received: from mx0b-001ae601.pphosted.com ([67.231.152.168]:56126 "EHLO mx0b-001ae601.pphosted.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750868AbdJFKB0 (ORCPT ); Fri, 6 Oct 2017 06:01:26 -0400 Authentication-Results: ppops.net; spf=none smtp.mailfrom=ckeepax@opensource.cirrus.com Date: Fri, 6 Oct 2017 11:00:59 +0100 From: Charles Keepax To: Nicholas Mc Guire CC: "Levin, Alexander (Sasha Levin)" , "linux-kernel@vger.kernel.org" , "stable@vger.kernel.org" , Nicholas Mc Guire , Stephen Boyd Subject: Re: [PATCH review for 4.4 12/47] clk: wm831x: fix usleep_range with bad range Message-ID: <20171006100059.725roshck2lwk25z@localhost.localdomain> References: <20170920044445.7392-1-alexander.levin@verizon.com> <20170920044445.7392-12-alexander.levin@verizon.com> <20170922084628.rh3ek2lfjc4fcqog@localhost.localdomain> <20170924001810.rqhntk7p4ryddnef@sasha-lappy> <20171006080323.GA25724@osadl.at> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline In-Reply-To: <20171006080323.GA25724@osadl.at> User-Agent: NeoMutt/20170113 (1.7.2) X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=2 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1707230000 definitions=main-1710060145 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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