public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Jens Axboe <jaxboe@fusionio.com>
To: Jeff Moyer <jmoyer@redhat.com>
Cc: "vgoyal@redhat.com" <vgoyal@redhat.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [patch] iosched: prevent aliased requests from starving other I/O
Date: Thu, 2 Jun 2011 13:07:46 +0200	[thread overview]
Message-ID: <4DE76F02.1090306@fusionio.com> (raw)
In-Reply-To: <x49tyc9y12s.fsf@segfault.boston.devel.redhat.com>

On 2011-06-01 18:21, Jeff Moyer wrote:
> Hi, Jens,
> 
> If you recall, I posted an RFC patch for this back in July of last year:
> http://lkml.org/lkml/2010/7/13/279
> 
> The basic problem is that a process can issue a never-ending stream of
> async direct I/Os to the same sector on a device, thus starving out
> other I/O in the system (due to the way the alias handling works in both
> cfq and deadline).  The solution I proposed back then was to start
> dispatching from the fifo after a certain number of aliases had been
> dispatched.  Vivek asked why we had to treat aliases differently at all,
> and I never had a good answer.  So, I put together a simple patch which
> allows aliases to be added to the rb tree (it adds them to the right,
> though that doesn't matter as the order isn't guaranteed anyway).  I
> think this is the preferred solution, as it doesn't break up time slices
> in CFQ or batches in deadline.  I've tested it, and it does solve the
> starvation issue.  Let me know what you think.

That'll work, there's no inherent reason why we can't have aliases
directly in the rbtree as long as the sort insert factors that into
account.

I will queue this one up for 3.1.

-- 
Jens Axboe


  reply	other threads:[~2011-06-02 11:07 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-06-01 16:21 [patch] iosched: prevent aliased requests from starving other I/O Jeff Moyer
2011-06-02 11:07 ` Jens Axboe [this message]
2011-06-02 11:09   ` Jens Axboe

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=4DE76F02.1090306@fusionio.com \
    --to=jaxboe@fusionio.com \
    --cc=jmoyer@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=vgoyal@redhat.com \
    /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