lkml.org 
[lkml]   [2010]   [Oct]   [18]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    SubjectRe: [PATCH v3 04/11] memcg: add lock to synchronize page accounting and migration
    From
    On Tue, Oct 19, 2010 at 9:39 AM, Greg Thelen <gthelen@google.com> wrote:
    > From: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
    >
    > From: KAMEZAWA Hiroyuki <kamezawa.hiroyu@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.hiroyu@jp.fujitsu.com>
    > Signed-off-by: Greg Thelen <gthelen@google.com>
    Reviewed-by: Minchan Kim <minchan.kim@gmail.com>


    --
    Kind regards,
    Minchan Kim
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

    \
     
     \ /
      Last update: 2010-10-19 03:21    [W:0.037 / U:29.560 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site