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: <20110322150905.GD3757@redhat.com>
Date:	Tue, 22 Mar 2011 11:09:05 -0400
From:	Vivek Goyal <vgoyal@...hat.com>
To:	Chad Talbott <ctalbott@...gle.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 Mon, Mar 21, 2011 at 06:10:42PM -0700, Chad Talbott wrote:
> This patchset introduces fair cross-group preemption.  Right now, we
> don't have strict isolation between processes in different cgroups.
> For example: currently an RT ioprio thread in one group can preempt a
> BE ioprio thread in another group.  We would like to have an
> application specify the relative priorities of its threads, but still
> allow strict isolation between applications.
> 
> With this patch series, we can configure an entire cgroup as needing
> low-latency service.  Then that group will be able to preempt another
> group.  To prevent a runaway application from starving other
> applications, we allow this preemption only until it has exceeded its
> fair share (as specified by its relative weight).  So a rate-limited,
> but latency sensative application (like streaming audio or video) can
> get front-of-the-line service without fear of it hogging a whole
> disk's IO.

Chad,

Why not just implement simply RT class groups and always allow an RT
group to preempt an BE class. Same thing we do for cfq queues. I will
not worry too much about a run away application consuming all the 
bandwidth. If that's a concern we could use blkio controller to limit
the IO rate of a latency sensitive applicaiton to make sure it does
not starve BE applications.

If RT starving BE is an issue, then it is an issue with plain cfq queue
also. First we shall have to fix it there.

This definition that a latency sensitive task get prioritized only
till it is consuming its fair share and if task starts using more than
fair share then CFQ automatically stops prioritizing it sounds little
odd to me. If you are looking for predictability, then we lost it. We
shall have to very well know that task is not eating more than its
fair share before we can gurantee any kind of latencies to that task. And
if we know that task is not hogging the disk, there is anyway no risk
of it starving other groups/tasks completely.

Or we could implement something where once in a while we do allow BE
class tasks to dispatch some IO so that RT tasks do not completely
starve BE class tasks. I guess this will be similar to what cpu scheduler
was trying where an RT tasks got 95% of cpu and 5% bandwidth was reserved
for admin to kill RT tasks if some RT tasks goes wild and locks up the
cpus.

Thanks
Vivek
--
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/