This is a discussion on Re: [patch 6/7] cpusets: per cpuset dirty ratios - Kernel ; 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 ...
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
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
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to firstname.lastname@example.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/