linux-kernel - Re: [PATCHSET] blk-throttle: implement proper hierarchy support

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:	Thu, 2 May 2013 14:17:48 -0400
From:	Vivek Goyal <vgoyal@...hat.com>
To:	Tejun Heo <tj@...nel.org>
Cc:	axboe@...nel.dk, linux-kernel@...r.kernel.org, lizefan@...wei.com,
	containers@...ts.linux-foundation.org, cgroups@...r.kernel.org
Subject: Re: [PATCHSET] blk-throttle: implement proper hierarchy support

On Thu, May 02, 2013 at 10:57:01AM -0700, Tejun Heo wrote:
> Hey, Vivek.
> 
> On Thu, May 02, 2013 at 01:34:28PM -0400, Vivek Goyal wrote:
> > On Wed, May 01, 2013 at 05:39:18PM -0700, Tejun Heo wrote:
> > 
> > [..]
> > > While this patchset contains many patches, the implementation is
> > > pretty straight-forward.  throtl_grp's form a tree anchored at
> > > throtl_data and bios climb the tree as they get dispatched at each
> > > level.  The bios which reach the top of the tree - throl_data - are
> > > issued. 
> > 
> > Have a question here. Looks like when bio climbs from child group
> > to parent group, then parent group slice starts fresh if parent
> > was empty. So if we have a parent with 1MB/s limit and a child with
> > 1MB/s limit and a bio gets queued in child, then looks like effective
> > IO rate would be .5MB/s and not 1MB/s?
> 
> Hmmm.... not that drastic but when the same limit is configured in
> both parent and its single active child, the child gets penalized by
> about 15%, which is not nice.

Sorry, did not understand how did you arrive at 15% penalty. I think
in worst case it will be 50%. Assume size of bio is 1MB. So it will
wait for 1 second in child group and then it will wait again for
another second in parent group. Assume next bio gets queued only
after first bio gets dispatched. 

That means each 1MB bio will wait for 2 second which will lead to
effective rate of .5MB/second.

> 
> > IOW, when child gets queued, we should start time accounting for
> > all parents in the hiearchy too.
> 
> I don't particularly like doing that as a separate step, maybe we can
> just push the child's start time to the parent while dispatching?
> Does that sound doable to you?

May be. But climbing the ladder has unfairness problems too. We might
have to rethink about the hierarchical algorithm altogether.

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/