summaryrefslogtreecommitdiffstats
path: root/kernel/cpuset.c
diff options
context:
space:
mode:
authorMichal Hocko <mhocko@suse.cz>2011-07-26 16:08:29 -0700
committerLinus Torvalds <torvalds@linux-foundation.org>2011-07-26 16:49:43 -0700
commit8521fc50d433507a7cdc96bec280f9e5888a54cc (patch)
treeb89d7b2eb34ba80b52e1f89ca767a86847df59b8 /kernel/cpuset.c
parent3e92041d68b40c47faa34c7dc08fc650a6c36adc (diff)
downloadop-kernel-dev-8521fc50d433507a7cdc96bec280f9e5888a54cc.zip
op-kernel-dev-8521fc50d433507a7cdc96bec280f9e5888a54cc.tar.gz
memcg: get rid of percpu_charge_mutex lock
percpu_charge_mutex protects from multiple simultaneous per-cpu charge caches draining because we might end up having too many work items. At least this was the case until commit 26fe61684449 ("memcg: fix percpu cached charge draining frequency") when we introduced a more targeted draining for async mode. Now that also sync draining is targeted we can safely remove mutex because we will not send more work than the current number of CPUs. FLUSHING_CACHED_CHARGE protects from sending the same work multiple times and stock->nr_pages == 0 protects from pointless sending a work if there is obviously nothing to be done. This is of course racy but we can live with it as the race window is really small (we would have to see FLUSHING_CACHED_CHARGE cleared while nr_pages would be still non-zero). The only remaining place where we can race is synchronous mode when we rely on FLUSHING_CACHED_CHARGE test which might have been set by other drainer on the same group but we should wait in that case as well. Signed-off-by: Michal Hocko <mhocko@suse.cz> Cc: Balbir Singh <bsingharora@gmail.com> Cc: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Diffstat (limited to 'kernel/cpuset.c')
0 files changed, 0 insertions, 0 deletions
OpenPOWER on IntegriCloud