Re: [Lsf-pc] [LSF/MM ATTEND] Filesystems -- Btrfs, cgroups, Storage topics from Facebook

[Tao Ma <tm@tao.ma>]

Hi Chris,
On 12/31/2013 09:19 PM, Chris Mason wrote:
> On Tue, 2013-12-31 at 13:45 퍝, 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 퍍, 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@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>