From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751879AbdEDVH3 (ORCPT ); Thu, 4 May 2017 17:07:29 -0400 Received: from host.buserror.net ([209.198.135.123]:52618 "EHLO host.buserror.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751423AbdEDVH2 (ORCPT ); Thu, 4 May 2017 17:07:28 -0400 Message-ID: <1493932034.25397.37.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: Thu, 04 May 2017 16:07:14 -0500 In-Reply-To: <1493873917-7484-1-git-send-email-karim.eshapa@gmail.com> References: <1493508775.25397.26.camel@buserror.net> <1493873917-7484-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 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? -Scott