All of lore.kernel.org
 help / color / mirror / Atom feed
From: Luse, Paul E <paul.e.luse at intel.com>
To: spdk@lists.01.org
Subject: Re: [SPDK] Problem with Blobstore when write 65MB continously
Date: Wed, 10 Jan 2018 17:02:51 +0000	[thread overview]
Message-ID: <82C9F782B054C94B9FC04A331649C77A9D492871@fmsmsx104.amr.corp.intel.com> (raw)
In-Reply-To: 1515603494.6063.32.camel@intel.com

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

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 before returning, was hoping for something like spdk_yield_thread() but of course didn't look first.  Do you think that might be useful or has this never come up before? 

Thx
Paul

-----Original Message-----
From: SPDK [mailto:spdk-bounces(a)lists.01.org] On Behalf Of Walker, Benjamin
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 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
_______________________________________________
SPDK mailing list
SPDK(a)lists.01.org
https://lists.01.org/mailman/listinfo/spdk

             reply	other threads:[~2018-01-10 17:02 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-01-10 17:02 Luse, Paul E [this message]
  -- strict thread matches above, loose matches on Subject: below --
2018-01-11  4:08 [SPDK] Problem with Blobstore when write 65MB continously Zhengyu Zhang
2018-01-10 20:53 Walker, Benjamin
2018-01-10 19:28 Andrey Kuzmin
2018-01-10 17:17 Walker, Benjamin
2018-01-10 17:11 Walker, Benjamin
2018-01-10 17:00 Andrey Kuzmin
2018-01-10 16:58 Walker, Benjamin
2018-01-10 16:47 Luse, Paul E
2018-01-10 16:32 Walker, Benjamin
2018-01-10 16:21 Harris, James R
2018-01-10 16:03 Luse, Paul E
2018-01-10 15:59 Zhengyu Zhang
2018-01-10 15:18 Luse, Paul E
2018-01-10 14:03 Luse, Paul E
2018-01-10  3:15 Zhengyu Zhang

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=82C9F782B054C94B9FC04A331649C77A9D492871@fmsmsx104.amr.corp.intel.com \
    --to=spdk@lists.01.org \
    /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
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.