Messages in this thread | | | Date | Mon, 26 Jul 2010 12:11:49 +0530 | From | Balbir Singh <> | Subject | Re: [RFC][PATCH 00/11] blkiocg async support |
| |
* Munihiro Ikeda <m-ikeda@ds.jp.nec.com> [2010-07-08 22:57:13]:
> These RFC patches are trial to add async (cached) write support on blkio > controller. > > Only test which has been done is to compile, boot, and that write bandwidth > seems prioritized when pages which were dirtied by two different processes in > different cgroups are written back to a device simultaneously. I know this > is the minimum (or less) test but I posted this as RFC because I would like > to hear your opinions about the design direction in the early stage. > > Patches are for 2.6.35-rc4. > > This patch series consists of two chunks. > > (1) iotrack (patch 01/11 -- 06/11) > > This is a functionality to track who dirtied a page, in exact which cgroup a > process which dirtied a page belongs to. Blkio controller will read the info > later and prioritize when the page is actually written to a block device. > This work is originated from Ryo Tsuruta and Hirokazu Takahashi and includes > Andrea Righi's idea. It was posted as a part of dm-ioband which was one of > proposals for IO controller. >
Does this reuse the memcg infrastructure, if so could you please add a summary of the changes here.
> > (2) blkio controller modification (07/11 -- 11/11) > > The main part of blkio controller async write support. > Currently async queues are device-wide and async write IOs are always treated > as root group. > These patches make async queues per a cfq_group per a device to control them. > Async write is handled by flush kernel thread. Because queue pointers are > stored in cfq_io_context, io_context of the thread has to have multiple > cfq_io_contexts per a device. So these patches make cfq_io_context per an > io_context per a cfq_group, which means per an io_context per a cgroup per a > device. > > > This might be a piece of puzzle for complete async write support of blkio > controller. One of other pieces in my head is page dirtying ratio control. > I believe Andrea Righi was working on it...how about the situation? >
Greg posted the last set of patches, we are yet to see another iteration.
> And also, I'm thinking that async write support is required by bandwidth > capping policy of blkio controller. Bandwidth capping can be done in upper > layer than elevator. However I think it should be also done in elevator layer > in my opinion. Elevator buffers and sort requests. If there is another > buffering functionality in upper layer, it is doubled buffering and it can be > harmful for elevator's prediction. >
-- Three Cheers, Balbir
| |