RFC blkiocg async support
Get series with b4
b4 am [email protected]Versions newest first
- v1 RFC Latest11 patches 41 repliesIn review
Patches in v1 No applies recorded yet
| # | Subject and files | Size | Replies | Applied |
|---|---|---|---|---|
| 1/11 | blkiocg async: Make page_cgroup independent from memory controllerinclude/ include/ init/ +1 more | +10 | 1 reply | |
| 2/11 | blkiocg async: The main part of iotrackblock/ block/ block/ +4 more | +309 | 7 replies | |
| 3/11 | blkiocg async: Hooks for iotrackfs/ fs/ mm/ +4 more | +17 | 2 replies | |
| 4/11 | blkiocg async: block_commit_write not to record process infofs/ include/ | +54 | 0 replies | |
| 5/11 | blkiocg async: __set_page_dirty_nobuffer not to record process infoinclude/ mm/ | +39 | 0 replies | |
| 6/11 | blkiocg async: ext4_writepage not to overwrite iotrack infofs/ | +1 | 0 replies | |
| 7/11 | blkiocg async: Pass bio to elevator_ops functionsblock/ block/ block/ +1 more | +19 | 0 replies | |
| 8/11 | blkiocg async: Function to search blkcg from css IDblock/ block/ | +14 | 0 replies | |
| 9/11 | blkiocg async: Functions to get cfqg from bioblock/ | +71 | 0 replies | |
| 10/11 | blkiocg async: Async queue per cfq_groupblock/ include/ | +175 | 4 replies | |
| 11/11 | blkiocg async: Workload timeslice adjustment for async queuesblock/ | +38 | 0 replies |
Reviews trailers per patch
1 of 11 patches has a Reviewed-by or Acked-by.
| Patch | Balbir Singh |
|---|---|
| 1/11 | A-b |
| 2/11 | |
| 3/11 | |
| 4/11 | |
| 5/11 | |
| 6/11 | |
| 7/11 | |
| 8/11 | |
| 9/11 | |
| 10/11 | |
| 11/11 |
Trailers given in replies are filled; those carried in the patches from earlier versions are outlined with dashes.
Cover letter [RFC][PATCH 00/11] blkiocg async support
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.
(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?
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.
I appreciate any comments and suggestions.
Thanks,
Muuhh
Signature · 3 lines
IKEDA, Munehiro
NEC Corporation of America
[email protected]