diff options
author | Michal Hocko <mhocko@suse.cz> | 2012-10-26 13:37:30 +0200 |
---|---|---|
committer | Tejun Heo <tj@kernel.org> | 2012-10-29 16:22:21 -0700 |
commit | 2ef37d3fe474b218e170010a59066e19427c9847 (patch) | |
tree | e458c8c9a2c981923a8b73a5ac8c5f943ccc894b /scripts/recordmcount.pl | |
parent | d842301181d9a4486aa24720ed4f96018b213292 (diff) | |
download | blackbird-op-linux-2ef37d3fe474b218e170010a59066e19427c9847.tar.gz blackbird-op-linux-2ef37d3fe474b218e170010a59066e19427c9847.zip |
memcg: Simplify mem_cgroup_force_empty_list error handling
mem_cgroup_force_empty_list currently tries to remove all pages from
the given LRU. To prevent from temoporary failures (EBUSY returned by
mem_cgroup_move_parent) it uses a margin to the current LRU pages and
returns the true if there are still some pages left on the list.
If we consider that mem_cgroup_move_parent fails only when it is racing
with somebody else removing (uncharging) the page or when the page is
migrated then it is obvious that all those failures are only temporal
and so we can safely retry later.
Let's get rid of the safety margin and make the loop really wait for
the empty LRU. The caller should still make sure that all charges have
been removed from the res_counter because mem_cgroup_replace_page_cache
might add a page to the LRU after the list_empty check (it doesn't touch
res_counter though).
This catches most of the cases except for shmem which might call
mem_cgroup_replace_page_cache with a page which is not charged and on
the LRU yet but this was the case also without this patch. In order to
fix this we need a guarantee that try_get_mem_cgroup_from_page falls
back to the current mm's cgroup so it needs css_tryget to fail. This
will be fixed up in a later patch because it needs a help from cgroup
core (pre_destroy has to be called after css is cleared).
Although mem_cgroup_pre_destroy can still fail (if a new task or a new
sub-group appears) there is no reason to retry pre_destroy callback from
the cgroup core. This means that __DEPRECATED_clear_css_refs has lost
its meaning and it can be removed.
Changes since v2
- remove __DEPRECATED_clear_css_refs
Changes since v1
- use kerndoc
- be more specific about mem_cgroup_move_parent possible failures
Signed-off-by: Michal Hocko <mhocko@suse.cz>
Reviewed-by: Tejun Heo <tj@kernel.org>
Reviewed-by: Glauber Costa <glommer@parallels.com>
Signed-off-by: Tejun Heo <tj@kernel.org>
Diffstat (limited to 'scripts/recordmcount.pl')
0 files changed, 0 insertions, 0 deletions