Messages in this thread | | | Date | Tue, 18 Nov 2008 15:42:39 +0800 | From | Li Zefan <> | Subject | Re: [patch 0/4] [RFC] Another proportional weight IO controller |
| |
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. >>>> >> >
| |