linux-kernel - Re: [RFC] block/throttle: Add IO throttled information in blkcg.

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: <4FBBA63B.1090401@tao.ma>
Date:	Tue, 22 May 2012 22:44:11 +0800
From:	Tao Ma <tm@....ma>
To:	Vivek Goyal <vgoyal@...hat.com>
CC:	linux-kernel@...r.kernel.org, Tejun Heo <tj@...nel.org>
Subject: Re: [RFC] block/throttle: Add IO throttled information in blkcg.

Hi Vivek,
	Thanks for the quick response.
On 05/22/2012 07:11 PM, Vivek Goyal wrote:
> On Tue, May 22, 2012 at 04:10:36PM +0800, Tao Ma wrote:
>> From: Tao Ma <boyu.mt@...bao.com>
>>
>> Currently, if the IO is throttled by io-throttle, the SA has no idea of
>> the situation and can't report it to the real application user about
>> that he/she has to do something. So this patch adds a new interface
>> named blkio.throttle.io_throttled which indicates how many IOs are
>> currently throttled.
> 
> If the only purpose is to know whether IOs are being throttled, why
> not just scan for the rules and see if respective device has any
> throttling rules or not.
Sorry, but setting a throttling rules doesn't mean the IOs are
throttled, right? So scanning doesn't work here IMHO.
> 
> Even if you introduce this interface, you will end up scanning for
> throttled ios against that particular device. And if IO is not happening
> at that moment or if IO rate is not exceeding the rate limit, there
> might not be any throttled ios and one might get misled.
Oh, no actually in a *clound computing* environment, it is really
useful, not misled. So let me describe it in more detail. Our product
system will limit every instance to an approximate number at first, and
then watch out the IOs being throttled. If these numbers is high, it can:
1) Shout loudly to the application programmer about the abuse if he
sends out too much IO requests.
2) If it is not too much and some other instances are not active, adjust
the throttled ratio so that this instance can work much faster.

All these 2 needs to know the throttled status for the cgroup and a
negative feedback is really useful for the elastic control of IO cgroups.
> 
> So for your purpose a better interface sounds like scanning for throttling
> rules instead of this new interface.
Sorry, as I have said above, I don't know how to get the current status
of the throttled IOs.
> 
>>
>> I am not sure whether it is OK to add this information to the generic
>> blkcg since it is only io-throttle related, but I don't find a way to
>> only store it into the blkcg io-throttle. And that's the reason this
>> is only a RFC. Any suggestions? Thanks.
> 
> Tejun has changed the code in this area and new code will allow you to
> introduce this file in blk-throttle.c. All that code is sitting in Jens's
> block tree.
Oh, cool, I will check that. Thanks.

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