linux-kernel - Re: [PATCH] cfq-iosched: Always provide group isolation.

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <4D6D4E89.5080406@fusionio.com>
Date:	Tue, 1 Mar 2011 14:52:41 -0500
From:	Jens Axboe <jaxboe@...ionio.com>
To:	Vivek Goyal <vgoyal@...hat.com>
CC:	Justin TerAvest <teravest@...gle.com>,
	"ctalbott@...gle.com" <ctalbott@...gle.com>,
	"mrubin@...gle.com" <mrubin@...gle.com>,
	"nauman@...gle.com" <nauman@...gle.com>,
	"guijianfeng@...fujitsu.com" <guijianfeng@...fujitsu.com>,
	"czoccolo@...il.com" <czoccolo@...il.com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] cfq-iosched: Always provide group isolation.

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

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/