Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
From:   Waiman Long <longman@redhat.com>
To:     Mike Kravetz <mike.kravetz@oracle.com>,
        Andrew Morton <akpm@linux-foundation.org>
Cc:     linux-kernel@vger.kernel.org, linux-mm@kvack.org,
        Davidlohr Bueso <dave@stgolabs.net>,
        Peter Zijlstra <peterz@infradead.org>,
        Ingo Molnar <mingo@redhat.com>,
        Will Deacon <will.deacon@arm.com>,
        Waiman Long <longman@redhat.com>
Subject: [PATCH] hugetlbfs: Take read_lock on i_mmap for PMD sharing
Date:   Thu,  7 Nov 2019 14:06:28 -0500
Message-Id: <20191107190628.22667-1-longman@redhat.com>
Content-Type: text/plain; charset=WINDOWS-1252
Content-Transfer-Encoding: quoted-printable
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

A customer with large SMP systems (up to 16 sockets) with application
that uses large amount of static hugepages (~500-1500GB) are experiencing
random multisecond delays. These delays was caused by the long time it
took to scan the VMA interval tree with mmap_sem held.

The sharing of huge PMD does not require changes to the i_mmap at all.
As a result, we can just take the read lock and let other threads
searching for the right VMA to share in parallel. Once the right
VMA is found, either the PMD lock (2M huge page for x86-64) or the
mm->page_table_lock will be acquired to perform the actual PMD sharing.

Lock contention, if present, will happen in the spinlock. That is much
better than contention in the rwsem where the time needed to scan the
the interval tree is indeterminate.

With this patch applied, the customer is seeing significant improvements
over the unpatched kernel.

Signed-off-by: Waiman Long <longman@redhat.com>
---
 mm/hugetlb.c | 8 ++++++--
 1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/mm/hugetlb.c b/mm/hugetlb.c
index b45a95363a84..087e7ff00137 100644
--- a/mm/hugetlb.c
+++ b/mm/hugetlb.c
@@ -4842,7 +4842,11 @@ pte_t *huge_pmd_share(struct mm_struct *mm, unsigned=
 long addr, pud_t *pud)
 =09if (!vma_shareable(vma, addr))
 =09=09return (pte_t *)pmd_alloc(mm, pud, addr);
=20
-=09i_mmap_lock_write(mapping);
+=09/*
+=09 * PMD sharing does not require changes to i_mmap. So a read lock
+=09 * is enuogh.
+=09 */
+=09i_mmap_lock_read(mapping);
 =09vma_interval_tree_foreach(svma, &mapping->i_mmap, idx, idx) {
 =09=09if (svma =3D=3D vma)
 =09=09=09continue;
@@ -4872,7 +4876,7 @@ pte_t *huge_pmd_share(struct mm_struct *mm, unsigned =
long addr, pud_t *pud)
 =09spin_unlock(ptl);
 out:
 =09pte =3D (pte_t *)pmd_alloc(mm, pud, addr);
-=09i_mmap_unlock_write(mapping);
+=09i_mmap_unlock_read(mapping);
 =09return pte;
 }
=20
--=20
2.18.1