lkml.org 
[lkml]   [2008]   [Aug]   [5]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    SubjectRe: Too many I/O controller patches
    From
    Hi, Andrea,

    I'm working with Ryo on dm-ioband and other stuff.

    > > On Mon, 2008-08-04 at 20:22 +0200, Andrea Righi wrote:
    > >> But I'm not yet convinced that limiting the IO writes at the device
    > >> mapper layer is the best solution. IMHO it would be better to throttle
    > >> applications' writes when they're dirtying pages in the page cache (the
    > >> io-throttle way), because when the IO requests arrive to the device
    > >> mapper it's too late (we would only have a lot of dirty pages that are
    > >> waiting to be flushed to the limited block devices, and maybe this could
    > >> lead to OOM conditions). IOW dm-ioband is doing this at the wrong level
    > >> (at least for my requirements). Ryo, correct me if I'm wrong or if I've
    > >> not understood the dm-ioband approach.
    > >
    > > The avoid-lots-of-page-dirtying problem sounds like a hard one. But, if
    > > you look at this in combination with the memory controller, they would
    > > make a great team.
    > >
    > > The memory controller keeps you from dirtying more than your limit of
    > > pages (and pinning too much memory) even if the dm layer is doing the
    > > throttling and itself can't throttle the memory usage.
    >
    > mmh... but in this way we would just move the OOM inside the cgroup,
    > that is a nice improvement, but the main problem is not resolved...

    The concept of dm-ioband includes it should be used with cgroup memory
    controller as well as the bio cgroup. The memory controller is supposed
    to control memory allocation and dirty-page ratio inside each cgroup.

    Some guys of cgroup memory controller team just started to implement
    the latter mechanism. They try to make each cgroup have a threshold
    to limit the number of dirty pages in the group.

    I feel this is good approach since each functions can work independently.

    > A safer approach IMHO is to force the tasks to wait synchronously on
    > each operation that directly or indirectly generates i/o.
    >
    > In particular the solution used by the io-throttle controller to limit
    > the dirty-ratio in memory is to impose a sleep via
    > schedule_timeout_killable() in balance_dirty_pages() when a generic
    > process exceeds the limits defined for the belonging cgroup.

    I guess it would make the memory controller team guys happier if you
    can help them design their dirty-page ratio controlling functionality
    much cooler and more generic. I think their goal is almost the same
    as yours.

    > Limiting read operations is a lot more easy, because they're always
    > synchronized with i/o requests.
    >
    > -Andrea

    Thank you,
    Hirokazu Takahashi.


    \
     
     \ /
      Last update: 2008-08-05 08:19    [W:2.349 / U:0.412 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site