Re: [patch 0/4] [RFC] Another proportional weight IO controller

[Li Zefan <lizf@cn.fujitsu.com>]

Nauman Rafique wrote:
> If we start with bfq patches, this is how plan would look like:
> 
> 1 Start with BFQ take 2.
> 2 Do the following to support proportional division:
>  a) Expose the per device weight interface to user, instead of calculating
>  from priority.
>  b) Add support for disk time budgets, besides sector budget that is currently
>  available (configurable option). (Fabio: Do you think we can just emulate
> that using the existing code?). Another approach would be to give time slices
> just like CFQ (discussing?)
> 4 Do the following to support the goals of 2 level schedulers:
>  a) Limit the request descriptors allocated to each cgroup by adding
>  functionality to elv_may_queue()
>  b) Add support for putting an absolute limit on IO consumed by a
>  cgroup. Such support is provided by Andrea
>  Righi's patches too.
>  c) Add support (configurable option) to keep track of total disk
> time/sectors/count
>  consumed at each device, and factor that into scheduling decision
>  (more discussion needed here)
> 6 Incorporate an IO tracking approach which re-uses memory resource
> controller code but is not dependent on it (may be biocgroup patches from
> dm-ioband can be used here directly)

The newest bio_cgroup doesn't use much memcg code I think. The older biocgroup
tracks IO using mem_cgroup_charge(), and mem_cgroup_charge() remembers a struct page
owns by which cgroup. But now biocgroup changes to directly put some hooks in
__set_page_dirty() and some other places to track pages.

> 7 Start an offline email thread to keep track of progress on the above
> goals.
> 
> BFQ's support for hierarchy of cgroups means that its close to where
> we want to get. Any comments on what approach looks better?
> 

Looks like a sane way :) . We are also trying to keep track of the discussion and
development of IO controller. I'll start to have a look into BFQ.

> On Mon, Nov 17, 2008 at 6:02 PM, Li Zefan <lizf@cn.fujitsu.com> wrote:
>> Vivek Goyal wrote:
>>> On Fri, Nov 14, 2008 at 02:44:22PM -0800, Nauman Rafique wrote:
>>>> In an attempt to make sure that this discussion leads to
>>>> something useful, we have summarized the points raised in this
>>>> discussion and have come up with a strategy for future.
>>>> The goal of this is to find common ground between all the approaches
>>>> proposed on this mailing list.
>>>>
>>>> 1 Start with Satoshi's latest patches.
>>> I have had a brief look at both Satoshi's patch and bfq. I kind of like
>>> bfq's patches for keeping track of per cgroup, per queue data structures.
>>> May be we can look there also.
>>>
>>>> 2 Do the following to support propotional division:
>>>>  a) Give time slices in proportion to weights (configurable
>>>>  option). We can support both priorities and weights by doing
>>>>  propotional division between requests with same priorities.
>>>> 3 Schedule time slices using WF2Q+ instead of round robin.
>>>>  Test the performance impact (both throughput and jitter in latency).
>>>> 4 Do the following to support the goals of 2 level schedulers:
>>>>  a) Limit the request descriptors allocated to each cgroup by adding
>>>>  functionality to elv_may_queue()
>>>>  b) Add support for putting an absolute limit on IO consumed by a
>>>>  cgroup. Such support exists in dm-ioband and is provided by Andrea
>>>>  Righi's patches too.
>>> Does dm-iobnd support abosolute limit? I think till last version they did
>>> not. I have not check the latest version though.
>>>
>> No, dm-ioband still provides weight/share control only. Only Andrea Righi's
>> patches support absolute limit.
> 
> Thanks for the correction.
> 
>>>>  c) Add support (configurable option) to keep track of total disk
>>>> time/sectors/count
>>>>  consumed at each device, and factor that into scheduling decision
>>>>  (more discussion needed here)
>>>> 5 Support multiple layers of cgroups to align IO controller behavior
>>>>  with CPU scheduling behavior (more discussion?)
>>>> 6 Incorporate an IO tracking approach which re-uses memory resource
>>>> controller code but is not dependent on it (may be biocgroup patches from
>>>> dm-ioband can be used here directly)
>>>> 7 Start an offline email thread to keep track of progress on the above
>>>> goals.
>>>>
>>>> Please feel free to add/modify items to the list
>>>> when you respond back. Any comments/suggestions are more than welcome.
>>>>
>>
>