From: Roy Pledge <roy.pledge@nxp.com> To: Scott Wood <oss@buserror.net>, Karim Eshapa <karim.eshapa@gmail.com> Cc: Claudiu Manoil <claudiu.manoil@nxp.com>, "colin.king@canonical.com" <colin.king@canonical.com>, "linuxppc-dev@lists.ozlabs.org" <linuxppc-dev@lists.ozlabs.org>, "linux-arm-kernel@lists.infradead.org" <linux-arm-kernel@lists.infradead.org>, "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org> Subject: Re: [PATCH v2] drivers:soc:fsl:qbman:qman.c: Sleep instead of stuck hacking jiffies. Date: Thu, 4 May 2017 23:30:05 +0000 [thread overview] Message-ID: <VI1PR04MB3216EC873ED7EB10F3D2CF9D86EA0@VI1PR04MB3216.eurprd04.prod.outlook.com> (raw) In-Reply-To: <1493932034.25397.37.camel@buserror.net> 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. Roy > > -Scott > >
next prev parent reply other threads:[~2017-05-04 23:30 UTC|newest] Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top 2017-04-29 19:46 [PATCH] " Karim Eshapa 2017-04-29 20:43 ` [PATCH] drivers:soc:fsl:qbman:qman.c: unsigned long jiffies value Karim Eshapa 2017-04-29 23:32 ` Scott Wood 2017-04-30 1:09 ` Karim Eshapa 2017-05-04 4:58 ` [PATCH v2] drivers:soc:fsl:qbman:qman.c: Sleep instead of stuck hacking jiffies Karim Eshapa 2017-05-04 21:07 ` Scott Wood 2017-05-04 23:30 ` Roy Pledge [this message] 2017-05-05 5:45 ` [PATCH v3] " Karim Eshapa 2017-06-25 2:46 ` [v3] " Scott Wood 2017-06-27 16:38 ` Leo Li 2017-05-05 6:01 ` [PATCH v2] " Karim Eshapa 2017-05-05 6:33 ` Scott Wood
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=VI1PR04MB3216EC873ED7EB10F3D2CF9D86EA0@VI1PR04MB3216.eurprd04.prod.outlook.com \ --to=roy.pledge@nxp.com \ --cc=claudiu.manoil@nxp.com \ --cc=colin.king@canonical.com \ --cc=karim.eshapa@gmail.com \ --cc=linux-arm-kernel@lists.infradead.org \ --cc=linux-kernel@vger.kernel.org \ --cc=linuxppc-dev@lists.ozlabs.org \ --cc=oss@buserror.net \ --subject='Re: [PATCH v2] drivers:soc:fsl:qbman:qman.c: Sleep instead of stuck hacking jiffies.' \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: link
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).