[lkml]   [2012]   [Apr]   [20]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [RFC] writeback and cgroup
    Hello, Fengguang.

    On Fri, Apr 20, 2012 at 09:34:41PM +0800, Fengguang Wu wrote:
    > > Yup. This just shows that you have to have per-cgroup dirty limits. Once
    > > you have those, things start working again.
    > Right. I think Tejun was more of less aware of this.

    I'm fairly sure I'm on the "less" side of it.

    > I was rather upset by this per-memcg dirty_limit idea indeed. I never
    > expect it to work well when used extensively. My plan was to set the
    > default memcg dirty_limit high enough, so that it's not hit in normal.
    > Then Tejun came and proposed to (mis-)use dirty_limit as the way to
    > convert the dirty pages' backpressure into real dirty throttling rate.
    > No, that's just crazy idea!

    I'll tell you what's crazy.

    We're not gonna cut three more kernel releases and then change jobs.
    Some of the stuff we put in the kernel ends up staying there for over
    a decade. While ignoring fundamental designs and violating layers may
    look like rendering a quick solution. They tend to come back and bite
    our collective asses. Ask Vivek. The iosched / blkcg API was messed
    up to the extent that bugs were so difficult to track down and it was
    nearly impossible to add new features, let alone new blkcg policy or
    elevator and people did suffer for that for long time. I ended up
    cleaning up the mess. It took me longer than three months and even
    then we have to carry on with a lot of ugly stuff for compatibility.

    Unfortunately, your proposed solution is far worse than blkcg was or
    ever could be. It's not even contained in a single subsystem and it's
    not even clear what it achieves. Neither weight or hard limit can be
    properly enforced without another layer of controlling at the block
    layer (some use cases do expect strict enforcement) and we're baking
    assumptions about use cases, interfaces and underlying hardware across
    multiple subsystems (some ssds work fine with per-iops switching).
    For your suggested solution, the moment it's best fit is now and it'll
    be a long painful way down until someone snaps and reimplements the
    whole thing.

    The kernel is larger than balance_dirty_pages() or writeback. Each
    subsystem should do what it's supposed to do. Let's solve problems
    where they belong and pay overheads where they're due. Let's not
    contort the whole stack for the short term goal of shoving writeback
    support into the existing, still-developing, blkcg cfq proportional IO
    implementation. Because that's pure insanity.



     \ /
      Last update: 2012-04-20 21:11    [W:0.025 / U:12.832 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site