Hi Nikita, thanks for your comments.
Nikita Danilov wrote: >> While Dirty+Writeback pages get more than 40% of memory, process-B is >> blocked in balance_dirty_pages() until writeback of some (`write_chunk', >> typically = 1536) dirty pages on disk-b is started. > > May be the simpler solution is to use separate variables to control > ratelimit and write chunk? No, I think it's difficult to throttle total Dirty+Writeback only with write_chunk, because write_chunk just affects Dirty and Writeback of each device (in this case, throttling is done in write-requests queue of the each backing device, as I said in another mail). Throttling of the total Dirty+Writeback should be also done in VM itself, and to control that, I added `dirty_limit_ratio.' > writeback_set_ratelimit() adjusts ratelimit_pages to avoid too frequent > calls to balance_dirty_pages(), but once we are inside of > writeback_inodes(), there is no need to write especially many pages in > one go: overhead of any additional looping is negligible, when compared > with the cost of writing. > > Speaking of which, now that expensive get_writeback_state() is gone from > page-writeback.c why do we need adjustable ratelimiting at all? It looks > like writeback_set_ratelimit() can be dropped, and fixed ratelimit used > instead. As far as I can see, adjustable ratelimiting is the actual cause of the long wait on writing to disk with light load. I think removing adjustable ratelimiting should be done in another patch... Regards -- Tomoki Sekiyama Hitachi, Ltd., Systems Development Laboratory - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
