Hi Chris, On 12/31/2013 09:19 PM, Chris Mason wrote: > On Tue, 2013-12-31 at 13:45 +0100, Jan Kara wrote: >> On Tue 31-12-13 16:49:27, Zheng Liu wrote: >>> Hi Chris, >>> >>> On Mon, Dec 30, 2013 at 09:36:20PM +0000, Chris Mason wrote: >>>> Hi everyone, >>>> >>>> I'd like to attend the LSF/MM conference this year. My current >>>> discussion points include: >>>> >>>> All things Btrfs! >>>> >>>> Adding cgroups for more filesystem resources, especially to limit the >>>> speed dirty pages are created. >>> >>> Interesting. If I remember correctly, IO-less dirty throttling has been >>> applied into upstream kernel, which can limit the speed that dirty pages >>> are created. Does it has any defect? >> It works as it should. But as Jeff points out, the throttling isn't >> cgroup aware. So it can happen that one memcg is full of dirty pages and >> reclaim has problems with reclaiming pages for it. I guess what Chris asks >> for is that we watch number of dirty pages in each memcg and throttle >> processes creating dirty pages in memcg which is close to its limit on >> dirty pages. > > Right, the ioless dirty throttling is fantastic, but it's based on the > BDI and you only get one of those per device. > > The current cgroup IO controller happens after we've decided to start > sending pages down. From a buffered write point of view, this is > already too late. If we delay the buffered IOs, the higher priority > tasks will just wait in balance_dirty_pages instead of waiting on the > drive. > > So I'd like to throttle the rate at which dirty pages are created, > preferably based on the rates currently calculated in the BDI of how > quickly the device is doing IO. This way we can limit dirty creation to > a percentage of the disk capacity during the current workload > (regardless of random vs buffered). Fengguang had already done some work on this, but it seems that the community does't have a consensus on where this control file should go. You can look at this link: https://lkml.org/lkml/2011/4/4/205 Thanks, Tao > > -chris > -- > To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in > the body of a message to majordomo@xxxxxxxxxxxxxxx > More majordomo info at http://vger.kernel.org/majordomo-info.html > -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
