linux.git/mm/memcontrol.c, branch v3.11

memcg: get rid of swapaccount leftovers

2013-08-23T16:51:22+00:00

The swapaccount kernel parameter without any values has been removed by
commit a2c8990aed5a ("memsw: remove noswapaccount kernel parameter") but
it seems that we didn't get rid of all the left overs.

Make sure that menuconfig help text and kernel-parameters.txt are clear
about value for the paramter and remove the stalled comment which is not
very much useful on its own.

Signed-off-by: Michal Hocko 
Reported-by: Gergely Risko 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

memcg: don't initialize kmem-cache destroying work for root caches

2013-08-14T00:57:47+00:00

struct memcg_cache_params has a union.  Different parts of this union
are used for root and non-root caches.  A part with destroying work is
used only for non-root caches.

I fixed the same problem in another place v3.9-rc1-16204-gf101a94, but
didn't notice this one.

This patch fixes the kernel panic:

[   46.848187] BUG: unable to handle kernel paging request at 000000fffffffeb8
[   46.849026] IP: [] kmem_cache_destroy_memcg_children+0x6c/0xc0
[   46.849092] PGD 0
[   46.849092] Oops: 0000 [#1] SMP
...

Signed-off-by: Andrey Vagin 
Cc: Glauber Costa 
Cc: Johannes Weiner 
Acked-by: Michal Hocko 
Cc: Balbir Singh 
Cc: KAMEZAWA Hiroyuki 
Cc: Konstantin Khlebnikov 
Cc:     [3.9.x]
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

vmpressure: make sure there are no events queued after memcg is offlined

2013-07-31T21:41:04+00:00

vmpressure is called synchronously from reclaim where the target_memcg
is guaranteed to be alive but the eventfd is signaled from the work
queue context.  This means that memcg (along with vmpressure structure
which is embedded into it) might go away while the work item is pending
which would result in use-after-release bug.

We have two possible ways how to fix this.  Either vmpressure pins memcg
before it schedules vmpr->work and unpin it in vmpressure_work_fn or
explicitely flush the work item from the css_offline context (as
suggested by Tejun).

This patch implements the later one and it introduces vmpressure_cleanup
which flushes the vmpressure work queue item item.  It hooks into
mem_cgroup_css_offline after the memcg itself is cleaned up.

[akpm@linux-foundation.org: coding-style fixes]
Signed-off-by: Michal Hocko 
Reported-by: Tejun Heo 
Cc: Anton Vorontsov 
Cc: Johannes Weiner 
Cc: KAMEZAWA Hiroyuki 
Cc: KOSAKI Motohiro 
Cc: Li Zefan 
Acked-by: Tejun Heo 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

kernel: delete __cpuinit usage from all core kernel files

2013-07-14T23:36:59+00:00

The __cpuinit type of throwaway sections might have made sense
some time ago when RAM was more constrained, but now the savings
do not offset the cost and complications.  For example, the fix in
commit 5e427ec2d0 ("x86: Fix bit corruption at CPU resume time")
is a good example of the nasty type of bugs that can be created
with improper use of the various __init prefixes.

After a discussion on LKML[1] it was decided that cpuinit should go
the way of devinit and be phased out.  Once all the users are gone,
we can then finally remove the macros themselves from linux/init.h.

This removes all the uses of the __cpuinit macros from C files in
the core kernel directories (kernel, init, lib, mm, and include)
that don't really have a specific maintainer.

[1] https://lkml.org/lkml/2013/5/20/589

Signed-off-by: Paul Gortmaker

memcg: don't need to free memcg via RCU or workqueue

2013-07-09T17:33:24+00:00

Now memcg has the same life cycle with its corresponding cgroup, and a
cgroup is freed via RCU and then mem_cgroup_css_free() will be called in
a work function, so we can simply call __mem_cgroup_free() in
mem_cgroup_css_free().

This actually reverts commit 59927fb984d ("memcg: free mem_cgroup by RCU
to fix oops").

Signed-off-by: Li Zefan 
Cc: Hugh Dickins 
Acked-by: Michal Hocko 
Acked-by: KAMEZAWA Hiroyuki 
Cc: Tejun Heo 
Cc: Glauber Costa 
Cc: Johannes Weiner 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

memcg: kill memcg refcnt

2013-07-09T17:33:24+00:00

Now memcg has the same life cycle as its corresponding cgroup.  Kill the
useless refcnt.

Signed-off-by: Li Zefan 
Acked-by: Michal Hocko 
Acked-by: KAMEZAWA Hiroyuki 
Cc: Hugh Dickins 
Cc: Tejun Heo 
Cc: Glauber Costa 
Cc: Johannes Weiner 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

memcg: don't need to get a reference to the parent

2013-07-09T17:33:24+00:00

The cgroup core guarantees it's always safe to access the parent.

Signed-off-by: Li Zefan 
Acked-by: Michal Hocko 
Acked-by: KAMEZAWA Hiroyuki 
Cc: Hugh Dickins 
Cc: Tejun Heo 
Cc: Glauber Costa 
Cc: Johannes Weiner 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

memcg: use css_get/put for swap memcg

2013-07-09T17:33:24+00:00

Use css_get/put instead of mem_cgroup_get/put.  A simple replacement
will do.

The historical reason that memcg has its own refcnt instead of always
using css_get/put, is that cgroup couldn't be removed if there're still
css refs, so css refs can't be used as long-lived reference.  The
situation has changed so that rmdir a cgroup will succeed regardless css
refs, but won't be freed until css refs goes down to 0.

Signed-off-by: Li Zefan 
Acked-by: Michal Hocko 
Acked-by: KAMEZAWA Hiroyuki 
Cc: Hugh Dickins 
Cc: Tejun Heo 
Cc: Glauber Costa 
Cc: Johannes Weiner 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

memcg: use css_get/put when charging/uncharging kmem

2013-07-09T17:33:24+00:00

Use css_get/put instead of mem_cgroup_get/put.

We can't do a simple replacement, because here mem_cgroup_put() is
called during mem_cgroup_css_free(), while mem_cgroup_css_free() won't
be called until css refcnt goes down to 0.

Instead we increment css refcnt in mem_cgroup_css_offline(), and then
check if there's still kmem charges.  If not, css refcnt will be
decremented immediately, otherwise the refcnt will be released after the
last kmem allocation is uncahred.

[akpm@linux-foundation.org: tweak comment]
Signed-off-by: Li Zefan 
Acked-by: Michal Hocko 
Acked-by: KAMEZAWA Hiroyuki 
Reviewed-by: Tejun Heo 
Cc: Michal Hocko 
Cc: Glauber Costa 
Cc: Johannes Weiner 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

memcg: don't use mem_cgroup_get() when creating a kmemcg cache

2013-07-09T17:33:24+00:00

Use css_get()/css_put() instead of mem_cgroup_get()/mem_cgroup_put().

There are two things being done in the current code:

First, we acquired a css_ref to make sure that the underlying cgroup
would not go away.  That is a short lived reference, and it is put as
soon as the cache is created.

At this point, we acquire a long-lived per-cache memcg reference count
to guarantee that the memcg will still be alive.

so it is:

  enqueue: css_get
  create : memcg_get, css_put
  destroy: memcg_put

So we only need to get rid of the memcg_get, change the memcg_put to
css_put, and get rid of the now extra css_put.

(This changelog is mostly written by Glauber)

Signed-off-by: Li Zefan 
Acked-by: Michal Hocko 
Acked-by: KAMEZAWA Hiroyuki 
Cc: Hugh Dickins 
Cc: Tejun Heo 
Cc: Glauber Costa 
Cc: Johannes Weiner 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds