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

Fengguang Wu fengguang.wu at intel.com
Tue Jun 19 13:47:42 UTC 2012


On Mon, Jun 18, 2012 at 10:52:13AM +0100, James Bottomley wrote:
> 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.

Thanks for the info. It's good to hear about the real use case and demands :)

> 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...)

It seems to me that the debates have been fruitful: it makes me and
the others better understand the problems and makes the pros-and-cons
much clearer than before. All that means once we decided to go either
way, we may make progress relatively fast without running into many
unexpected obstacles.

I'm more than willing to take the easy path. However it seems rather
hard to avoid the proliferations of writeback pages when the async IO
queue is slitted up. Well.. I'm still wondering if there are easier
3rd way out...

Thanks,
Fengguang


More information about the Ksummit-2012-discuss mailing list