From mboxrd@z Thu Jan 1 00:00:00 1970 Content-Type: multipart/mixed; boundary="===============7336020250138617542==" MIME-Version: 1.0 From: Walker, Benjamin Subject: Re: [SPDK] Problem with Blobstore when write 65MB continously Date: Wed, 10 Jan 2018 16:58:15 +0000 Message-ID: <1515603494.6063.32.camel@intel.com> In-Reply-To: 82C9F782B054C94B9FC04A331649C77A9D4927B9@fmsmsx104.amr.corp.intel.com List-ID: To: spdk@lists.01.org --===============7336020250138617542== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable On Wed, 2018-01-10 at 16:47 +0000, Luse, Paul E wrote: > Damn, I should have known that :( Thanks guys!! = > = > So I'll take the easy way out and just ask.. what's the most efficient wa= y for > an app, designed just this one for whatever reason, essentially relinquish > control to the event reactor - is there a single call he can slip into the > loop to give other pending events, if any a chance to run and if not cont= inue > on submitting? Return from the function submitting I/O after submitting a certain number a= nd resume submitting new I/O in response to completion callbacks. > = > Thx > Paul > = > -----Original Message----- > From: SPDK [mailto:spdk-bounces(a)lists.01.org] On Behalf Of Walker, Benj= amin > Sent: Wednesday, January 10, 2018 9:33 AM > To: freeman.zhang1992(a)gmail.com; spdk(a)lists.01.org > Subject: Re: [SPDK] Problem with Blobstore when write 65MB continously > = > On Wed, 2018-01-10 at 16:21 +0000, Harris, James R wrote: > > Hi Paul and Zhengyu, > > = > > The problem is that the app is not giving the block device a chance to = > > complete any I/O while submitting the 520 back-to-back requests. = > > Blobstore is passive here =E2=80=93 it does not do any polling on the b= lock = > > device =E2=80=93 that is up to the application. > = > To additionally clarify - the bdev layer will poll for completions on your > behalf, but it does so on the same thread that you are submitting I/O fro= m. If > you are in a tight loop submitting I/O and never yield back to the event > reactor, the polling won't have a chance to occur. You can either increas= e the > number of reqs per channel or submit smaller batches at a time. Basically= , do > what Jim said below. > = > > Increasing the number of channel reqs would work =E2=80=93 but at some = point = > > these will still run out. So it really depends on your application =E2= =80=93 = > > either increase the channel reqs to the absolutely maximum you will = > > ever need, or add ENOMEM handling. > = > _______________________________________________ > SPDK mailing list > SPDK(a)lists.01.org > https://lists.01.org/mailman/listinfo/spdk > _______________________________________________ > SPDK mailing list > SPDK(a)lists.01.org > https://lists.01.org/mailman/listinfo/spdk --===============7336020250138617542==--