linux-kernel - Re: [RFC v1] add new io-scheduler to use cgroup on high-speed device

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]

Date:	Wed, 5 Jun 2013 10:36:14 -0700
From:	Tejun Heo <tj@...nel.org>
To:	Vivek Goyal <vgoyal@...hat.com>
Cc:	Robin Dong <sanbai@...bao.com>, linux-kernel@...r.kernel.org,
	Zhu Yanhai <gaoyang.zyh@...bao.com>,
	Jens Axboe <axboe@...nel.dk>, Tao Ma <taoma.tm@...il.com>,
	kent.overstreet@...il.com
Subject: Re: [RFC v1] add new io-scheduler to use cgroup on high-speed device

Hello, Vivek.

On Wed, Jun 05, 2013 at 09:55:12AM -0400, Vivek Goyal wrote:
> I think it will be hard to cover all the use cases. There is a reason
> why CFQ got so complicated and bulky because it tried to cover all the
> use cases and provide service differentiation among workloads. blk-cgroup
> will try to do the same thing at group level. All these question will
> arise when to idle, how much to idle, how much device queue depth we
> should drive to keep service differention better, how much outstanding
> IO from each group we should allow in the queue.

Yes but that's because we were trying to serve disks with rotating
platters.  I don't think we can use the same thing for disks and
non-rotational devices.  For the latter, things get a lot simpler.
Note that even the current blk-throttle doesn't care about the
underlying device at all.  We can do the same thing for proportional
control in a hopefully better and scalable way of course.

> And all of this affects what kind of service differentation you see
> on different devices for different workloads.
> 
> I think generic implementation can be written with the goal of trying to
> make it work with faster flash devices (which will typically use blk-mq).
> And for slower disks, one can continue to use CFQ's cgroup implementation.

Yeap.  Pretty much the same feeling here.

> On a side note, it would be nice if we handle problem of managing buffered
> writes using cgroup first. Otherwise there are very few practical
> scenarios where proportional IO thing can be used.

Indeed.  It's currently below unified hierarchy in my todo list but if
you wanna tackle it, I'll be happy to help.

Thanks.

-- 
tejun
--
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/