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:09:21 +0200 [thread overview]
Message-ID: <4DE76F61.7060409@fusionio.com> (raw)
In-Reply-To: <4DE76F02.1090306@fusionio.com>
On 2011-06-02 13:07, Jens Axboe wrote:
> 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.
Jeff, care to resend a "proper" patch (signed-off and so forth)?
--
Jens Axboe
prev parent reply other threads:[~2011-06-02 11:09 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
2011-06-02 11:09 ` Jens Axboe [this message]
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=4DE76F61.7060409@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 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.