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

Fengguang Wu fengguang.wu at intel.com
Sun Jun 17 03:17:52 UTC 2012


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.

- 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,
Fengguang


More information about the Ksummit-2012-discuss mailing list