[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <20240811212129.3074314-1-yuzhao@google.com>
Date: Sun, 11 Aug 2024 15:21:26 -0600
From: Yu Zhao <yuzhao@...gle.com>
To: Andrew Morton <akpm@...ux-foundation.org>, Muchun Song <muchun.song@...ux.dev>
Cc: "Matthew Wilcox (Oracle)" <willy@...radead.org>, Zi Yan <ziy@...dia.com>, linux-mm@...ck.org,
linux-kernel@...r.kernel.org, Yu Zhao <yuzhao@...gle.com>
Subject: [PATCH mm-unstable v1 0/3] mm/hugetlb: alloc/free gigantic folios
Use __GFP_COMP for gigantic folios can greatly reduce not only the
complexity in the code but also the allocation and free time.
Approximate LOC to mm/hugetlb.c: -200, +50
Allocate and free 500 1GB hugeTLB memory without HVO by:
time echo 500 >/sys/kernel/mm/hugepages/hugepages-1048576kB/nr_hugepages
time echo 0 >/sys/kernel/mm/hugepages/hugepages-1048576kB/nr_hugepages
Before After
Alloc ~13s ~10s
Free ~15s <1s
The above magnitude generally holds for multiple x86 and arm64 CPU
models.
Yu Zhao (3):
mm/contig_alloc: support __GFP_COMP
mm/cma: add cma_alloc_folio()
mm/hugetlb: use __GFP_COMP for gigantic folios
include/linux/cma.h | 1 +
include/linux/hugetlb.h | 9 +-
mm/cma.c | 47 +++++---
mm/compaction.c | 48 +-------
mm/hugetlb.c | 244 ++++++++--------------------------------
mm/internal.h | 9 ++
mm/page_alloc.c | 111 +++++++++++++-----
7 files changed, 177 insertions(+), 292 deletions(-)
base-commit: b447504e1fed49fabbc03d6c2530126824f87c92
prerequisite-patch-id: 9fe502f7c87a9f951d0aee61f426bd85bc43ef74
--
2.46.0.76.ge559c4bf1a-goog
Powered by blists - more mailing lists