lkml.org 
[lkml]   [2013]   [May]   [2]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCHSET] blk-throttle: implement proper hierarchy support
On Thu, May 02, 2013 at 11:44:26AM -0700, Tejun Heo wrote:

[..]
> Also, if you're actually thinking about reimplementing blk-throttle,
> please do consider the followings.
>
> * Currently, blk-throttle doesn't throttle the number of bios being
> queued. Note that this breaks the basic back-pressure mechanism
> where IO pressure is propagated back to the issuer by throttling the
> issuing task. blk-throttle breaks that link and converts it to a
> memory pressure.

Agreed. Implementing something along the lines of per group nr_requests
is needed.

>
> * It's almost inherently unscalable with highops devices. Given that
> IO limiting doesn't require very fine granularity, I think doing
> this per-cpu shouldn't be too hard. e.g. build a per-cpu token
> distributing hierarchy with rebalancing across CPUs happening
> periodically.

Interesting. I thought for highops devices we will these multi queue
patches from jens and there we can probably implement per queue tokens
and rebalance tokens across queues periodically.

>
> In short, right now, the goal is getting the hierarchy support
> acceptably working ASAP and yeap we wanna get the nested limits and at
> least certain level of fairness, but let's please implement something
> simple for now and strive for sophistification later because it's
> holding back everyone else.

I am fine with this. Having some hierarchical algorithm and not blocking
full hierarchical support for cgroup is better than not having any
hierachical support and wait for better implementation.

Thanks
Vivek


\
 
 \ /
  Last update: 2013-05-02 21:21    [W:0.064 / U:0.252 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site