| Message ID | 20240329073750.20012-1-21cnbao@gmail.com (mailing list archive) |
|---|---|
| State | New |
| Headers | show |
| Series | mm: alloc_anon_folio: avoid doing vma_thp_gfp_mask in fallback cases | expand |
On Fri, Mar 29, 2024 at 3:38 AM Barry Song <21cnbao@gmail.com> wrote: > > From: Barry Song <v-songbaohua@oppo.com> > > Fallback rates surpassing 90% have been observed on phones utilizing 64KiB > CONT-PTE mTHP. In these scenarios, when one out of every 16 PTEs fails > to allocate large folios, the remaining 15 PTEs fallback. Consequently, > invoking vma_thp_gfp_mask seems redundant in such cases. Furthermore, > abstaining from its use can also contribute to improved code readability. Acked-by: Yu Zhao <yuzhao@google.com>
On 29 Mar 2024, at 3:37, Barry Song wrote: > From: Barry Song <v-songbaohua@oppo.com> > > Fallback rates surpassing 90% have been observed on phones utilizing 64KiB > CONT-PTE mTHP. In these scenarios, when one out of every 16 PTEs fails > to allocate large folios, the remaining 15 PTEs fallback. Consequently, > invoking vma_thp_gfp_mask seems redundant in such cases. Furthermore, > abstaining from its use can also contribute to improved code readability. > > Cc: Ryan Roberts <ryan.roberts@arm.com> > Cc: Kefeng Wang <wangkefeng.wang@huawei.com> > Cc: John Hubbard <jhubbard@nvidia.com> > Cc: David Hildenbrand <david@redhat.com> > Cc: Alistair Popple <apopple@nvidia.com> > Cc: Anshuman Khandual <anshuman.khandual@arm.com> > Cc: Catalin Marinas <catalin.marinas@arm.com> > Cc: David Rientjes <rientjes@google.com> > Cc: "Huang, Ying" <ying.huang@intel.com> > Cc: Hugh Dickins <hughd@google.com> > Cc: Itaru Kitayama <itaru.kitayama@gmail.com> > Cc: Kirill A. Shutemov <kirill.shutemov@linux.intel.com> > Cc: Luis Chamberlain <mcgrof@kernel.org> > Cc: Matthew Wilcox (Oracle) <willy@infradead.org> > Cc: Vlastimil Babka <vbabka@suse.cz> > Cc: Yang Shi <shy828301@gmail.com> > Cc: Yin Fengwei <fengwei.yin@intel.com> > Cc: Yu Zhao <yuzhao@google.com> > Cc: Zi Yan <ziy@nvidia.com> > Signed-off-by: Barry Song <v-songbaohua@oppo.com> > --- > mm/memory.c | 3 +++ > 1 file changed, 3 insertions(+) LGTM. Reviewed-by: Zi Yan <ziy@nvidia.com> -- Best Regards, Yan, Zi
On 29/03/2024 07:37, Barry Song wrote: > From: Barry Song <v-songbaohua@oppo.com> > > Fallback rates surpassing 90% have been observed on phones utilizing 64KiB > CONT-PTE mTHP. In these scenarios, when one out of every 16 PTEs fails > to allocate large folios, the remaining 15 PTEs fallback. Consequently, > invoking vma_thp_gfp_mask seems redundant in such cases. Furthermore, > abstaining from its use can also contribute to improved code readability. > > Cc: Ryan Roberts <ryan.roberts@arm.com> > Cc: Kefeng Wang <wangkefeng.wang@huawei.com> > Cc: John Hubbard <jhubbard@nvidia.com> > Cc: David Hildenbrand <david@redhat.com> > Cc: Alistair Popple <apopple@nvidia.com> > Cc: Anshuman Khandual <anshuman.khandual@arm.com> > Cc: Catalin Marinas <catalin.marinas@arm.com> > Cc: David Rientjes <rientjes@google.com> > Cc: "Huang, Ying" <ying.huang@intel.com> > Cc: Hugh Dickins <hughd@google.com> > Cc: Itaru Kitayama <itaru.kitayama@gmail.com> > Cc: Kirill A. Shutemov <kirill.shutemov@linux.intel.com> > Cc: Luis Chamberlain <mcgrof@kernel.org> > Cc: Matthew Wilcox (Oracle) <willy@infradead.org> > Cc: Vlastimil Babka <vbabka@suse.cz> > Cc: Yang Shi <shy828301@gmail.com> > Cc: Yin Fengwei <fengwei.yin@intel.com> > Cc: Yu Zhao <yuzhao@google.com> > Cc: Zi Yan <ziy@nvidia.com> > Signed-off-by: Barry Song <v-songbaohua@oppo.com> Reviewed-by: Ryan Roberts <ryan.roberts@arm.com> > --- > mm/memory.c | 3 +++ > 1 file changed, 3 insertions(+) > > diff --git a/mm/memory.c b/mm/memory.c > index c9c1031c2ecb..010e7bb20d2b 100644 > --- a/mm/memory.c > +++ b/mm/memory.c > @@ -4353,6 +4353,9 @@ static struct folio *alloc_anon_folio(struct vm_fault *vmf) > > pte_unmap(pte); > > + if (!orders) > + goto fallback; > + > /* Try allocating the highest of the remaining orders. */ > gfp = vma_thp_gfp_mask(vma); > while (orders) {
diff --git a/mm/memory.c b/mm/memory.c index c9c1031c2ecb..010e7bb20d2b 100644 --- a/mm/memory.c +++ b/mm/memory.c @@ -4353,6 +4353,9 @@ static struct folio *alloc_anon_folio(struct vm_fault *vmf) pte_unmap(pte); + if (!orders) + goto fallback; + /* Try allocating the highest of the remaining orders. */ gfp = vma_thp_gfp_mask(vma); while (orders) {