linux-kernel - Re: [PATCH 0/3] cfq-iosched: Fair cross-group preemption

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <AANLkTikTLCdHceaD98zxw90Qb=PuTvfALWELa=Yp6UAC@mail.gmail.com>
Date:	Fri, 25 Mar 2011 16:53:13 -0700
From:	Chad Talbott <ctalbott@...gle.com>
To:	Vivek Goyal <vgoyal@...hat.com>,
	Gui Jianfeng <guijianfeng@...fujitsu.com>
Cc:	jaxboe@...ionio.com, linux-kernel@...r.kernel.org,
	mrubin@...gle.com, teravest@...gle.com
Subject: Re: [PATCH 0/3] cfq-iosched: Fair cross-group preemption

On Fri, Mar 25, 2011 at 2:32 PM, Vivek Goyal <vgoyal@...hat.com> wrote:
>> You seem pretty unenthusiastic about a).  How do you feel about b)?
>
> IMHO, Using RT group with throttling avoids introducing asymmetry between
> task and group attributes. So I will prefer that approch. Though it means
> more code as we will be introducing RT groups but that might be useful
> in general for something else too. (I am assuming that somebody makes
> use of RT class for cfqq).
>
> The one more down side of trying to use throttling is that one needs to
> come up with absolute limit. So one shall have to know disk capacity
> and if there are no BE tasks running then latency sensitive task will
> be unnecessarily throttled (until and unless some management software
> can monitor it and change limit dynamically).
>
> So if you are worried about setting the absolute limit part, then I guess
> I am fine with option a). But if you think that setting absolute limit
> is not a problem, then option b) is preferred.

I prefer option a) - so much so that even with the older CFQ group
implementation we did work to merge the RT and BE service trees to
achieve that behavior.  But I see that using blkio.class is a poor
choice of interface name.  I will rename the interface and resubmit
the patch series (also with Gui's suggestion to keep the "_device"
suffix for consistency).

Also, we'll soon be working to adopt the hierarchy series, and we'll
likely revisit using an RT service tree there.  It's difficult to
justify introducing RT service tree before those patches arrive.

Thanks,
Chad
--
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/