From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from psmtp.com (na3sys010amx102.postini.com [74.125.245.102]) by kanga.kvack.org (Postfix) with SMTP id CCAFD6B005D for ; Tue, 4 Dec 2012 21:59:39 -0500 (EST) Received: by mail-vc0-f169.google.com with SMTP id gb23so4715108vcb.14 for ; Tue, 04 Dec 2012 18:59:38 -0800 (PST) MIME-Version: 1.0 In-Reply-To: <20121202151232.GB12911@gmail.com> References: <1354305521-11583-1-git-send-email-mingo@kernel.org> <20121201094927.GA12366@gmail.com> <20121201122649.GA20322@gmail.com> <20121201184135.GA32449@gmail.com> <20121201201538.GB2704@gmail.com> <50BA69B7.30002@redhat.com> <20121202151232.GB12911@gmail.com> Date: Tue, 4 Dec 2012 18:59:38 -0800 Message-ID: Subject: Re: [PATCH 2/2, v2] mm/migration: Make rmap_walk_anon() and try_to_unmap_anon() more scalable From: Michel Lespinasse Content-Type: text/plain; charset=ISO-8859-1 Sender: owner-linux-mm@kvack.org List-ID: To: Ingo Molnar Cc: Rik van Riel , Linus Torvalds , Linux Kernel Mailing List , linux-mm , Peter Zijlstra , Paul Turner , Lee Schermerhorn , Christoph Lameter , Mel Gorman , Andrew Morton , Andrea Arcangeli , Thomas Gleixner , Johannes Weiner , Hugh Dickins On Sun, Dec 2, 2012 at 7:12 AM, Ingo Molnar wrote: > Subject: [PATCH] mm/rmap, migration: Make rmap_walk_anon() and > try_to_unmap_anon() more scalable > > rmap_walk_anon() and try_to_unmap_anon() appears to be too > careful about locking the anon vma: while it needs protection > against anon vma list modifications, it does not need exclusive > access to the list itself. > > Transforming this exclusive lock to a read-locked rwsem removes > a global lock from the hot path of page-migration intense > threaded workloads which can cause pathological performance like > this: > > 96.43% process 0 [kernel.kallsyms] [k] perf_trace_sched_switch > | > --- perf_trace_sched_switch > __schedule > schedule > schedule_preempt_disabled > __mutex_lock_common.isra.6 > __mutex_lock_slowpath > mutex_lock > | > |--50.61%-- rmap_walk > | move_to_new_page > | migrate_pages > | migrate_misplaced_page > | __do_numa_page.isra.69 > | handle_pte_fault > | handle_mm_fault > | __do_page_fault > | do_page_fault > | page_fault > | __memset_sse2 > | | > | --100.00%-- worker_thread > | | > | --100.00%-- start_thread > | > --49.39%-- page_lock_anon_vma > try_to_unmap_anon > try_to_unmap > migrate_pages > migrate_misplaced_page > __do_numa_page.isra.69 > handle_pte_fault > handle_mm_fault > __do_page_fault > do_page_fault > page_fault > __memset_sse2 > | > --100.00%-- worker_thread > start_thread > > With this change applied the profile is now nicely flat > and there's no anon-vma related scheduling/blocking. Wouldn't the same reasoning apply to i_mmap_mutex ? Should we make that a rwsem as well ? I take it that Ingo's test case does not show this, but i_mmap_mutex's role with file pages is actually quite similar to the anon_vma lock with anon pages... -- Michel "Walken" Lespinasse A program is never fully debugged until the last user dies. -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: email@kvack.org