lkml.org 
[lkml]   [2008]   [Oct]   [30]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [patch 6/7] cpusets: per cpuset dirty ratios
    On Wed, 29 Oct 2008, Paul Menage wrote:

    > Wouldn't this be equally applicable to cgroups using the memory
    > controller rather than cpusets? Might it make sense to have a common
    > subsystem that could be used by either of them?
    >

    This change give us two functional advantages for cpusets that aren't
    possible with the memcontroller.

    First, it allows for cpu isolation. I see this as more of a NUMA issue
    than memory controller issue since we're throttling dirty writeout for
    current's set of allowable nodes in the reclaim path to the set of cpus
    that pdflush can use. This allows a couple of things:

    - disjoint (and cpu-exclusive) cpusets with latency sensitive tasks are
    unaffected by a flood of synchronous dirty writeback, and

    - we preserve NUMA locality and its optimizations for pages under
    writeback.

    Second, it allows for targeted dirty ratios. The memcontroller doesn't
    allow us to determine if, for instance, the background dirty ratio has
    been exceeded for a set of tasks assigned to a specific cgroup since we
    can't determine its amount of dirtyable memory or NR_FILE_DIRTY pages
    (they're stored as ZVC values in the VM and aren't collected by the memory
    controller).

    David


    \
     
     \ /
      Last update: 2008-10-30 09:51    [W:0.049 / U:35.560 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site