Re: [SPDK] Problem with Blobstore when write 65MB continously

[Walker, Benjamin <benjamin.walker at intel.com>]

[-- Attachment #1: Type: text/plain, Size: 2262 bytes --]

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 and
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 – it does not do any polling on the block 
> > device – 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 – but at some point 
> > these will still run out.  So it really depends on your application – 
> > 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