On Mon, 18 Oct 2010 17:39:37 -0700 Greg Thelen <gthe...@google.com> wrote:
> From: KAMEZAWA Hiroyuki <kamezawa.hir...@jp.fujitsu.com> > > From: KAMEZAWA Hiroyuki <kamezawa.hir...@jp.fujitsu.com> > > Introduce a new bit spin lock, PCG_MOVE_LOCK, to synchronize > the page accounting and migration code. This reworks the > locking scheme of _update_stat() and _move_account() by > adding new lock bit PCG_MOVE_LOCK, which is always taken > under IRQ disable. > > 1. If pages are being migrated from a memcg, then updates to > that memcg page statistics are protected by grabbing > PCG_MOVE_LOCK using move_lock_page_cgroup(). In an > upcoming commit, memcg dirty page accounting will be > updating memcg page accounting (specifically: num > writeback pages) from IRQ context (softirq). Avoid a > deadlocking nested spin lock attempt by disabling irq on > the local processor when grabbing the PCG_MOVE_LOCK. > > 2. lock for update_page_stat is used only for avoiding race > with move_account(). So, IRQ awareness of > lock_page_cgroup() itself is not a problem. The problem > is between mem_cgroup_update_page_stat() and > mem_cgroup_move_account_page(). > > Trade-off: > * Changing lock_page_cgroup() to always disable IRQ (or > local_bh) has some impacts on performance and I think > it's bad to disable IRQ when it's not necessary. > * adding a new lock makes move_account() slower. Score is > here. > > Performance Impact: moving a 8G anon process. > > Before: > real 0m0.792s > user 0m0.000s > sys 0m0.780s > > After: > real 0m0.854s > user 0m0.000s > sys 0m0.842s > > This score is bad but planned patches for optimization can reduce > this impact. > > Signed-off-by: KAMEZAWA Hiroyuki <kamezawa.hir...@jp.fujitsu.com> > Signed-off-by: Greg Thelen <gthe...@google.com> This approach is more straightforward and easy to understand. Acked-by: Daisuke Nishimura <nishim...@mxp.nes.nec.co.jp> _______________________________________________ Containers mailing list contain...@lists.linux-foundation.org https://lists.linux-foundation.org/mailman/listinfo/containers _______________________________________________ Devel mailing list Devel@openvz.org https://openvz.org/mailman/listinfo/devel
