linux-nvme.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: axboe@kernel.dk (Jens Axboe)
Subject: RFC: Allow block drivers to poll for I/O instead of sleeping
Date: Tue, 25 Jun 2013 17:00:21 +0200	[thread overview]
Message-ID: <20130625150021.GM5594@kernel.dk> (raw)
In-Reply-To: <20130625031809.GB8211@linux.intel.com>

On Mon, Jun 24 2013, Matthew Wilcox wrote:
> On Mon, Jun 24, 2013@10:07:51AM +0200, Ingo Molnar wrote:
> > I'm wondering, how will this scheme work if the IO completion latency is a 
> > lot more than the 5 usecs in the testcase? What if it takes 20 usecs or 
> > 100 usecs or more?
> 
> There's clearly a threshold at which it stops making sense, and our
> current NAND-based SSDs are almost certainly on the wrong side of that
> threshold!  I can't wait for one of the "post-NAND" technologies to make
> it to market in some form that makes it economical to use in an SSD.
> 
> The problem is that some of the people who are looking at those
> technologies are crazy.  They want to "bypass the kernel" and "do user
> space I/O" because "the kernel is too slow".  This patch is part of an
> effort to show them how crazy they are.  And even if it doesn't convince
> them, at least users who refuse to rewrite their applications to take
> advantage of magical userspace I/O libraries will see real performance
> benefits.

Fully concur with that. At least on the read side, nand is just getting
crappier and polled completions is usually not going to be great. On the
write side, however, there are definite gains. Completions in the
10-15usec range aren't unusual. And once we hit PCM, well, it'll be fun.

On the write side, there are plenty of super latency customers out there
who would LOVE to poll when/if it's useful. Most often also the same
kind of people who talk the crazy of putting everything in user space.
Which is why I like the polling. If we can get sufficiently close, then
we can shut some of that up.

-- 
Jens Axboe

  parent reply	other threads:[~2013-06-25 15:00 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-06-20 20:17 RFC: Allow block drivers to poll for I/O instead of sleeping Matthew Wilcox
2013-06-23 10:09 ` Ingo Molnar
2013-06-23 18:29   ` Linus Torvalds
2013-06-24  7:17     ` Jens Axboe
2013-06-25  0:11       ` Steven Rostedt
2013-06-25  3:07         ` Matthew Wilcox
2013-06-25 13:57           ` Steven Rostedt
2013-06-25 14:57         ` Jens Axboe
2013-06-24  8:07     ` Ingo Molnar
2013-06-25  3:18       ` Matthew Wilcox
2013-06-25  7:07         ` Bart Van Assche
2013-06-25 15:00         ` Jens Axboe [this message]
2013-06-27 18:10     ` Rik van Riel
2013-06-23 22:14   ` David Ahern
2013-06-24  8:21     ` Ingo Molnar
2013-06-24  7:15   ` Jens Axboe
2013-06-24  8:18     ` Ingo Molnar
2013-06-25  3:01     ` Matthew Wilcox
2013-06-25 14:55       ` Jens Axboe
2013-06-27 18:42 ` Rik van Riel
2013-07-04  1:13 ` Shaohua Li

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=20130625150021.GM5594@kernel.dk \
    --to=axboe@kernel.dk \
    /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 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).