From: Sidhartha Kumar <sidhartha.kumar@oracle.com>
To: linux-kernel@vger.kernel.org, linux-mm@kvack.org
Cc: akpm@linux-foundation.org, songmuchun@bytedance.com,
mike.kravetz@oracle.com, willy@infradead.org, david@redhat.com,
nphamcs@gmail.com, jthoughton@google.com,
Sidhartha Kumar <sidhartha.kumar@oracle.com>
Subject: [PATCH 0/2] change ->index to PAGE_SIZE for hugetlb pages
Date: Fri, 9 Jun 2023 12:49:45 -0700 [thread overview]
Message-ID: <20230609194947.37196-1-sidhartha.kumar@oracle.com> (raw)
========================== OVERVIEW ========================================
This patchset attempts to implement a listed filemap TODO which is
changing hugetlb folios to have ->index in PAGE_SIZE. This simplifies many
functions within filemap.c as they have to special case hugetlb pages.
From the RFC v1[1], Mike pointed out that hugetlb will still have to maintain
a huge page sized index as it is used for the reservation map and the hash
function for the hugetlb mutex table.
This patchset adds new wrappers for hugetlb code to to interact with the
page cache. These wrappers calculate a linear page index as this is now
what the page cache expects for hugetlb pages.
From the discussion on HGM for hugetlb[3], there is a want to remove hugetlb
special casing throughout the core mm code. This series accomplishes
a part of this by shifting complexity from filemap.c to hugetlb.c. There
are still checks for hugetlb within the filemap code as cgroup accounting
and hugetlb accounting are special cased as well.
=========================== PERFORMANCE =====================================
The time spent in hugetlb_add_to_page_cache() and __filemap_get_folio() was
tracked while running the LTP hugetlb testcases. The units are in nanoseconds.
6.4.0-rc5
@hugetlb_add_to_page_cache:
[512, 1K) 7518 |@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@|
[1K, 2K) 158 |@ |
[2K, 4K) 30 | |
[4K, 8K) 6 | |
[8K, 16K) 9 | |
6.4.0-rc5 + this patch series
@hugetlb_add_to_page_cache:
[512, 1K) 6400 |@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@|
[1K, 2K) 1230 |@@@@@@@@@ |
[2K, 4K) 55 | |
[4K, 8K) 16 | |
[8K, 16K) 19 | |
[16K, 32K) 1 |
6.4.0-rc5
@__filemap_get_folio:
[256, 512) 11292 |@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@|
[512, 1K) 4615 |@@@@@@@@@@@@@@@@@@@@@ |
[1K, 2K) 960 |@@@@ |
[2K, 4K) 188 | |
[4K, 8K) 68 | |
[8K, 16K) 14 | |
[16K, 32K) 4 | |
[2G, 4G) 4 | |
6.4.0-rc5 + this patch series
@__filemap_get_folio:
[128, 256) 4 | |
[256, 512) 11068 |@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@|
[512, 1K) 3334 |@@@@@@@@@@@@@@@ |
[1K, 2K) 559 |@@ |
[2K, 4K) 112 | |
[4K, 8K) 42 | |
[8K, 16K) 7 | |
[16K, 32K) 2 | |
[2G, 4G) 3 | |
This performance characteristics are similar after the patch with slightly more
latency in hugetlb_add_to_page_cache() seen by the increase of events within the
[1K, 2K) bucket. Please let me know if I should test more functions for performance
impact.
=========================== TESTING ==========================================
This series passes the LTP hugetlb test cases.
RFC v2[2]-> v1:
-cleanup code style
RFC v1 -> v2
-change direction of series to maintain both huge and base page size index
rather than try to get rid of all references to a huge page sized index.
rebased on 06/09/2023 mm-unstable
[1]:https://lore.kernel.org/lkml/20230425012721.GA6696@monkey/T/
[2]:https://lore.kernel.org/linux-mm/20230519220142.212051-1-sidhartha.kumar@oracle.com/T/
[3]:https://lore.kernel.org/linux-mm/a49e7ec8-735d-5a81-1744-cb887389a559@google.com/T/#r78a847a834671a9a7095c9458d9a1737015e7d0b
Sidhartha Kumar (2):
mm/filemap: remove hugetlb special casing in filemap.c
mm/hugetlb: add wrapper functions for interactions with page cache
fs/hugetlbfs/inode.c | 14 +++++++-------
include/linux/hugetlb.h | 21 +++++++++++++++++++--
include/linux/pagemap.h | 8 --------
mm/filemap.c | 36 +++++++++++-------------------------
mm/hugetlb.c | 22 +++++++++++++---------
5 files changed, 50 insertions(+), 51 deletions(-)
--
2.40.1
next reply other threads:[~2023-06-09 19:50 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-06-09 19:49 Sidhartha Kumar [this message]
2023-06-09 19:49 ` [PATCH 1/2] mm/filemap: remove hugetlb special casing in filemap.c Sidhartha Kumar
2023-06-09 20:05 ` Matthew Wilcox
2023-06-09 20:18 ` Sidhartha Kumar
2023-06-15 22:13 ` Mike Kravetz
2023-06-09 19:49 ` [PATCH 2/2] mm/hugetlb: add wrapper functions for interactions with page cache Sidhartha Kumar
2023-06-09 19:52 ` Sidhartha Kumar
2023-06-15 23:36 ` Mike Kravetz
2023-06-16 18:52 ` Sidhartha Kumar
2023-06-16 23:41 ` Mike Kravetz
2023-06-09 20:10 ` Matthew Wilcox
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20230609194947.37196-1-sidhartha.kumar@oracle.com \
--to=sidhartha.kumar@oracle.com \
--cc=akpm@linux-foundation.org \
--cc=david@redhat.com \
--cc=jthoughton@google.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mike.kravetz@oracle.com \
--cc=nphamcs@gmail.com \
--cc=songmuchun@bytedance.com \
--cc=willy@infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).