public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Jens Axboe <jaxboe@fusionio.com>
To: Vivek Goyal <vgoyal@redhat.com>
Cc: Justin TerAvest <teravest@google.com>,
	"ctalbott@google.com" <ctalbott@google.com>,
	"mrubin@google.com" <mrubin@google.com>,
	"nauman@google.com" <nauman@google.com>,
	"guijianfeng@cn.fujitsu.com" <guijianfeng@cn.fujitsu.com>,
	"czoccolo@gmail.com" <czoccolo@gmail.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] cfq-iosched: Always provide group isolation.
Date: Tue, 1 Mar 2011 14:52:41 -0500	[thread overview]
Message-ID: <4D6D4E89.5080406@fusionio.com> (raw)
In-Reply-To: <20110301192937.GC2539@redhat.com>

On 2011-03-01 14:29, Vivek Goyal wrote:
> On Tue, Mar 01, 2011 at 11:13:18AM -0800, Justin TerAvest wrote:
>> Effectively, make group_isolation=1 the default and remove the tunable.
>> The setting group_isolation=0 was because by default we idle on
>> sync-noidle tree and on fast devices, this can be very harmful for
>> throughput.
>>
>> However, this problem can also be addressed by tuning slice_idle and
>> possibly group_idle on faster storage devices.
>>
>> This change simplifies the CFQ code by removing the feature entirely.
> 
> I have not come across anybody so far who wants to get isolation only
> for sequential queues and not for random cfq queues, hence I think
> it makes sense to remove this tunable to reduce the complexity.
> 
> Secondly, on faster devices if idling hurts, I think disabling idling
> is the only solution and that will either reduce or wipe out any
> service differentiation one was getting.
> 
> So I am fine with removing this tunable. Anyobdy else has got a use
> case for this?

It arguably should never have been added. We need to be more careful in
the future about adding tunables like this. Basically nobody ever
touches them, even if how to use them are described in detail. I'd argue
that this group_isolation was probably only ever used when it was added
and testing was done.

> Jens, do we have to worry about ABI regarding this sysfs tunable?

No, tunables like this have come and gone before. So we can kill this
for .39, I'll queue it up.


-- 
Jens Axboe


      reply	other threads:[~2011-03-01 19:52 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-03-01 19:13 [PATCH] cfq-iosched: Always provide group isolation Justin TerAvest
2011-03-01 19:29 ` Vivek Goyal
2011-03-01 19:52   ` 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=4D6D4E89.5080406@fusionio.com \
    --to=jaxboe@fusionio.com \
    --cc=ctalbott@google.com \
    --cc=czoccolo@gmail.com \
    --cc=guijianfeng@cn.fujitsu.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mrubin@google.com \
    --cc=nauman@google.com \
    --cc=teravest@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