linux-kernel - Re: [patch 6/7] cpusets: per cpuset dirty ratios

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <alpine.DEB.2.00.0810300119560.29094@chino.kir.corp.google.com>
Date:	Thu, 30 Oct 2008 01:48:22 -0700 (PDT)
From:	David Rientjes <rientjes@...gle.com>
To:	Paul Menage <menage@...gle.com>
cc:	Andrew Morton <akpm@...ux-foundation.org>,
	Christoph Lameter <cl@...ux-foundation.org>,
	Nick Piggin <npiggin@...e.de>,
	Peter Zijlstra <peterz@...radead.org>,
	Derek Fults <dfults@....com>, linux-kernel@...r.kernel.org
Subject: Re: [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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/