mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Jeff Moyer <jmoyer@redhat.com>
To: Vivek Goyal <vgoyal@redhat.com>
Cc: linux kernel mailing list <linux-kernel@vger.kernel.org>,
	Jens Axboe <axboe@kernel.dk>,
	Corrado Zoccolo <czoccolo@gmail.com>,
	Nauman Rafique <nauman@google.com>,
	Divyesh Shah <dpshah@google.com>,
	Gui Jianfeng <guijianfeng@cn.fujitsu.com>
Subject: Re: [RFC/RFT PATCH] cfq-iosched: Implement cfq group idling
Date: Thu, 08 Jul 2010 10:08:44 -0400	[thread overview]
Message-ID: <x49r5jedq1f.fsf@segfault.boston.devel.redhat.com> (raw)
In-Reply-To: <20100708135625.GD5093@redhat.com> (Vivek Goyal's message of "Thu, 8 Jul 2010 09:56:25 -0400")

Vivek Goyal <vgoyal@redhat.com> writes:

> On Thu, Jul 08, 2010 at 09:39:45AM -0400, Jeff Moyer wrote:
>> Vivek Goyal <vgoyal@redhat.com> writes:
>> 
>> > Currently we idle on sequential queues and allow dispatch from a single
>> > queue and that can become a bottleneck on higher end storage. For example
>> > on my HP EVA, I can run multiple sequential streams and achieve top BW
>> > of around 350 MB/s. But with CFQ, dispatching from single queue does not
>> > keep the array busy (limits to 150-180 MB/s with 4 or 8 processes).
>> >
>> > One approach to solve this issue is simply use slice_idle = 0. But this
>> > also takes away the any service differentiation between groups.
>> 
>> That also takes away service differentiation between queues.  If you
>> want to maintain that at all, then this is really just pushing the
>> problem to another layer.
>> 
>
> Yes it does take away the io priority with-in group. But I think that's
> the trade-off and that's not default. So those who don't require ioprio
> stuff working with-in group and those who know that they have got
> faster storage will set slice_idle=0. For rest of the SATA users default
> is still slice_idle=8.

[snip]

Sorry, Vivek, I'm actually hijacking your thread.  ;-)  I know what the
alternatives are, what I'm looking for is guidance on what Jens wants to
do with CFQ.  We can discuss the merits of different approaches once we
agree on a set of requirements.

Cheers,
Jeff

  reply	other threads:[~2010-07-08 14:09 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-07-07 23:05 Vivek Goyal
2010-07-08  5:53 ` Nauman Rafique
2010-07-08 13:13   ` Vivek Goyal
2010-07-08 15:32     ` Vivek Goyal
2010-07-08 22:52       ` Vivek Goyal
2010-07-08 13:39 ` Jeff Moyer
2010-07-08 13:56   ` Vivek Goyal
2010-07-08 14:08     ` Jeff Moyer [this message]
2010-07-08 15:15       ` Corrado Zoccolo

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=x49r5jedq1f.fsf@segfault.boston.devel.redhat.com \
    --to=jmoyer@redhat.com \
    --cc=axboe@kernel.dk \
    --cc=czoccolo@gmail.com \
    --cc=dpshah@google.com \
    --cc=guijianfeng@cn.fujitsu.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=nauman@google.com \
    --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

all inboxes | Powered by JetHome®