From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755458AbdEEGdn (ORCPT ); Fri, 5 May 2017 02:33:43 -0400 Received: from host.buserror.net ([209.198.135.123]:52828 "EHLO host.buserror.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752037AbdEEGdm (ORCPT ); Fri, 5 May 2017 02:33:42 -0400 Message-ID: <1493966009.25397.39.camel@buserror.net> From: Scott Wood To: Karim Eshapa Cc: claudiu.manoil@nxp.com, roy.pledge@nxp.com, colin.king@canonical.com, linuxppc-dev@lists.ozlabs.org, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org Date: Fri, 05 May 2017 01:33:29 -0500 In-Reply-To: <1493964114-11296-1-git-send-email-karim.eshapa@gmail.com> References: <1493873917-7484-1-git-send-email-karim.eshapa@gmail.com> <1493964114-11296-1-git-send-email-karim.eshapa@gmail.com> Organization: NXP Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.22.6-1ubuntu1 Mime-Version: 1.0 Content-Transfer-Encoding: 8bit X-SA-Exim-Connect-IP: 50.171.225.118 X-SA-Exim-Rcpt-To: karim.eshapa@gmail.com, claudiu.manoil@nxp.com, roy.pledge@nxp.com, colin.king@canonical.com, linuxppc-dev@lists.ozlabs.org, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org X-SA-Exim-Mail-From: oss@buserror.net X-Spam-Report: * -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP * -15 BAYES_00 BODY: Bayes spam probability is 0 to 1% * [score: 0.0000] * -1.5 GREYLIST_ISWHITE The incoming server has been whitelisted for this * recipient and sender Subject: Re: [PATCH v2] drivers:soc:fsl:qbman:qman.c: Sleep instead of stuck hacking jiffies. X-SA-Exim-Version: 4.2.1 (built Mon, 26 Dec 2011 16:57:07 +0000) X-SA-Exim-Scanned: Yes (on host.buserror.net) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, 2017-05-05 at 08:01 +0200, Karim Eshapa wrote: > > On 5/4/2017 5:07 PM, Scott Wood wrote: > > > On Thu, 2017-05-04 at 06:58 +0200, Karim Eshapa wrote: > > > > +    stop = jiffies + 10000; > > > > +    /* > > > > +     * if MR was full and h/w had other FQRNI entries to produce, we > > > > +     * need to allow it time to produce those entries once the > > > > +     * existing entries are consumed. A worst-case situation > > > > +     * (fully-loaded system) means h/w sequencers may have to do 3-4 > > > > +     * other things before servicing the portal's MR pump, each of > > > > +     * which (if slow) may take ~50 qman cycles (which is ~200 > > > > +     * processor cycles). So rounding up and then multiplying this > > > > +     * worst-case estimate by a factor of 10, just to be > > > > +     * ultra-paranoid, goes as high as 10,000 cycles. NB, we consume > > > > +     * one entry at a time, so h/w has an opportunity to produce new > > > > +     * entries well before the ring has been fully consumed, so > > > > +     * we're being *really* paranoid here. > > > > +     */ > > > > > > OK, upon reading this more closely it seems the intent was to delay for > > > 10,000 > > > *processor cycles* and somehow that got turned into 10,000 jiffies > > > (which is > > > 40 seconds at the default Hz!).  We could just replace this whole thing > > > with > > > msleep(1) and still be far more paranoid than was originally intended. > > > > > > Claudiu and Roy, any comments? > > > > Yes the timing here is certainly off, the code changed a few times since > > the comment was originally written. > > An msleep(1) seems reasonable here to me. > > If the previous patch with msleep(1) is OK. > can I send a patch to slightly change the comments. Yes. -Scott