[lkml]   [2008]   [Oct]   [30]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
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

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


 \ /
  Last update: 2008-10-30 09:51    [W:0.070 / U:5.300 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site