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

James Bottomley James.Bottomley at HansenPartnership.com
Mon Jun 18 09:52:13 UTC 2012


On Mon, 2012-06-18 at 09:20 +0900, Kamezawa Hiroyuki wrote:
> (2012/06/17 12:17), Fengguang Wu 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.
> >
> > - 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.
> 
> 
> Yes, topics seems interesting to me. I think we should have cgroup+writeback
> breakout session.

Yes, me too.  At parallels, we're currently concentrating on the basics
of getting per-cgroup slab limiting (which is needed to prevent IaaS
containers DoSing each other), but we'll be interested in I/O bandwidth
limiting right after this.  There is some current overlap in that part
of the slab limits becomes a writeback problem when the shrinkers get
activated.

Plus, if we can't reach agreement, I'd really like to see Fengguang bite
all the MM/FS developers (speaking as a storage developer, naturally...)

James




More information about the Ksummit-2012-discuss mailing list