linux-kernel - Re: [RFC 0/3] block: proportional based blk-throttling

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: <20160122144334.GC9499@redhat.com>
Date:	Fri, 22 Jan 2016 09:43:34 -0500
From:	Vivek Goyal <vgoyal@...hat.com>
To:	Tejun Heo <tj@...nel.org>
Cc:	Shaohua Li <shli@...com>, linux-kernel@...r.kernel.org,
	axboe@...nel.dk, jmoyer@...hat.com, Kernel-team@...com
Subject: Re: [RFC 0/3] block: proportional based blk-throttling

On Thu, Jan 21, 2016 at 05:41:57PM -0500, Tejun Heo wrote:

[..]
> A simple approximation of IO cost such as fixed cost
> per IO + cost proportional to IO size would do a far better job than
> just depending on bandwidth or iops and that requires approximating
> two variables over time.  I'm not sure how easy / feasible that
> actually would be tho.

Hi Tejun,

"A fixed cost per IO sounds" like iops and "cost proportional to IO size"
sounds like bandwidth. I am wondering can we dynamically control both
bps and iops rate of cgroup based on cgroup weight and average bw/iops of
device queue. That way a cgroup can not get unfair share of disk neither
by throwing lots of small IOs, nor by sending down a small number of large
IOs.

Will that be good enough.

Thanks
Vivek