From mboxrd@z Thu Jan 1 00:00:00 1970 Content-Type: multipart/mixed; boundary="===============0801437406126619080==" MIME-Version: 1.0 From: Luse, Paul E Subject: Re: [SPDK] Problem with Blobstore when write 65MB continously Date: Wed, 10 Jan 2018 17:02:51 +0000 Message-ID: <82C9F782B054C94B9FC04A331649C77A9D492871@fmsmsx104.amr.corp.intel.com> In-Reply-To: 1515603494.6063.32.camel@intel.com List-ID: To: spdk@lists.01.org --===============0801437406126619080== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable OK yeah that makes sense, one could experiment with batching some number of= requests and counting through callbacks to find a good number to submit be= fore returning, was hoping for something like spdk_yield_thread() but of co= urse didn't look first. Do you think that might be useful or has this neve= r come up before? = Thx Paul -----Original Message----- From: SPDK [mailto:spdk-bounces(a)lists.01.org] On Behalf Of Walker, Benjam= in Sent: Wednesday, January 10, 2018 9:58 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: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 = > way 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 continue 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, = > Benjamin > 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 from. 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 increase 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 yo= u = > > 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 _______________________________________________ SPDK mailing list SPDK(a)lists.01.org https://lists.01.org/mailman/listinfo/spdk --===============0801437406126619080==--