[Ksummit-2012-discuss] [ATTEND] writeback and kernel testing

Balbir Singh bsingharora at gmail.com
Mon Jun 18 09:27:52 UTC 2012


On Sun, Jun 17, 2012 at 8:47 AM, Fengguang Wu <fengguang.wu at intel.com> wrote:
> On Sun, Jun 17, 2012 at 08:03:15AM +0530, Balbir Singh wrote:
>> On Sat, Jun 16, 2012 at 6:14 PM, Fengguang Wu <fengguang.wu at intel.com> wrote:
>> > Greetings,
>> >
>> > I'd like to attend this year's kernel summit.
>> >
>> > I may talk about the technical challenges and trade-offs on writeback and memcg
>> > and IO controllers with anyone interested, perhaps in some breakout session.
>> >
>>
>> Do you have a reference for the tests you've mentioned. Do you have a
>> brief summary of the challenges and trade-offs?
>
> - memcg with dirty limits
>
>  The basic agreements are, we'll do per-memcg dirty limit, but set the
>  limits reasonably high and do not expose interfaces to user space.
>

No interfaces in user-space, how is it expected to work via the global limits?

> - write_bps IO controller, where write_bps accounts both buffered/direct IO
>
>  It seems that it's possible to do a write_bps max bandwidth
>  controller at the high layer. Vivek can also extend the existing
>  controller in the block layer. The two approaches may coexist nicely.
>
>  Re: Integrated IO controller for buffered+direct writes
>  https://lkml.org/lkml/2012/4/23/70
>
> - proportional IO controller with buffered write support
>
>  Well it's a hard problem and we've not yet reached consensus.
>  Here is the thread with lots of details:
>
>  [RFC] writeback and cgroup
>  https://lkml.org/lkml/2012/4/3/314
>
>  Basically, Tejun's approach costs some IO/CPU/interactive
>  performance and could considerably increase writeback pages which
>  will have big problems supporting dozens of cgroups. While my
>  approach is perfectly scalable, but involves balance_dirty_pages()
>  <=> IO scheduler interactions and will be challenging to implement.
>
>  Currently my attitude is,
>
>  - I won't go straight off to implement the balance_dirty_pages()
>    based approach without general acknowledgements beforehand.
>
>  - The writeback pages problem must be addressed to remove my NAK,
>    otherwise I believe it will go and bite the MM/FS developers soon.
>

Thanks for the summary

Balbir


More information about the Ksummit-2012-discuss mailing list