Hi,
On 02/27/2012 07:58 PM, Suleiman Souhlal wrote:
This patch series introduces kernel memory accounting to memcg.
It currently only accounts for slab.
It's very similar to the patchset I sent back in October, but
with a number of fixes and improvements.
There is also overlap with Glauber's
On 02/27/2012 07:58 PM, Suleiman Souhlal wrote:
Enabled with CONFIG_CGROUP_MEM_RES_CTLR_KMEM.
Adds the following files:
- memory.kmem.independent_kmem_limit
- memory.kmem.usage_in_bytes
- memory.kmem.limit_in_bytes
Signed-off-by: Suleiman Souhlalsulei...@google.com
---
On 02/27/2012 07:58 PM, Suleiman Souhlal wrote:
Enabled with CONFIG_CGROUP_MEM_RES_CTLR_KMEM.
Adds the following files:
- memory.kmem.independent_kmem_limit
- memory.kmem.usage_in_bytes
- memory.kmem.limit_in_bytes
Signed-off-by: Suleiman Souhlalsulei...@google.com
---
On 02/27/2012 07:58 PM, Suleiman Souhlal wrote:
Introduce per-cgroup kmem_caches for memcg slab accounting, that
get created the first time we do an allocation of that type in the
cgroup.
If we are not permitted to sleep in that allocation, the cache
gets created asynchronously.
And then we
On 02/27/2012 07:58 PM, Suleiman Souhlal wrote:
From: Hugh Dickinshu...@google.com
If __mem_cgroup_try_charge() goes the bypass route in charging slab
(typically when the task has been OOM-killed), that later results in
res_counter_uncharge_locked() underflows - a stream of warnings from
On 02/27/2012 07:58 PM, Suleiman Souhlal wrote:
This config option dictates whether or not kernel memory in the
root cgroup should be accounted.
This may be useful in an environment where everything is supposed to be
in a cgroup and accounted for. Large amounts of kernel memory in the
root
On 02/27/2012 07:58 PM, Suleiman Souhlal wrote:
A later patch will also use this to move the accounting to the root
cgroup.
Suleiman,
Did you do any measurements to figure out how long does it take,
average, for dangling caches to go away ? Under memory pressure, let's say
On 02/23/2012 04:18 PM, Ying Han wrote:
On Tue, Feb 21, 2012 at 3:34 AM, Glauber Costaglom...@parallels.com wrote:
This is a first structured approach to tracking general kernel
memory within the memory controller. Please tell me what you think.
As previously proposed, one has the option of
On Tue, 28 Feb 2012 15:36:27 -0800
Suleiman Souhlal sulei...@google.com wrote:
On Tue, Feb 28, 2012 at 5:34 AM, Glauber Costa glom...@parallels.com wrote:
On 02/27/2012 07:58 PM, Suleiman Souhlal wrote:
This config option dictates whether or not kernel memory in the
root cgroup should be
On Mon, 27 Feb 2012 14:58:47 -0800
Suleiman Souhlal ssouh...@freebsd.org wrote:
This is used to indicate that we don't want an allocation to be accounted
to the current cgroup.
Signed-off-by: Suleiman Souhlal sulei...@google.com
I don't like this.
Please add
___GFP_ACCOUNT account this
On Mon, 27 Feb 2012 14:58:46 -0800
Suleiman Souhlal ssouh...@freebsd.org wrote:
From: Hugh Dickins hu...@google.com
mem_cgroup_do_charge() was written before slab accounting, and expects
three cases: being called for 1 page, being called for a stock of 32 pages,
or being called for a
On Mon, 27 Feb 2012 14:58:45 -0800
Suleiman Souhlal ssouh...@freebsd.org wrote:
A later patch will also use this to move the accounting to the root
cgroup.
Signed-off-by: Suleiman Souhlal sulei...@google.com
---
mm/memcontrol.c | 30 +-
1 files changed, 29
12 matches
Mail list logo
