From: Mike Kravetz <mike.kravetz@oracle.com>
To: Sidhartha Kumar <sidhartha.kumar@oracle.com>
Cc: linux-kernel@vger.kernel.org, linux-mm@kvack.org,
akpm@linux-foundation.org, willy@infradead.org,
songmuchun@bytedance.com, david@redhat.com
Subject: Re: [PATCH v2 0/1] change ->index to PAGE_SIZE for hugetlb pages
Date: Wed, 19 Jul 2023 17:00:11 -0700 [thread overview]
Message-ID: <20230720000011.GD3240@monkey> (raw)
In-Reply-To: <20230710230450.110064-1-sidhartha.kumar@oracle.com>
On 07/10/23 16:04, Sidhartha Kumar wrote:
> ========================== 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 =====================================
Hi Sid,
Sorry for being dense but can you tell me what the below performance
information means. My concern with such a change would be any noticeable
difference in populating a large (up to TB) hugetlb file. My guess is
that it is going to take longer unless xarray is optimized for this.
We do have users that create and pre-populate hugetlb files this big.
Just want to make sure there are no surprises for them.
--
Mike Kravetz
> 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.5.0-rc1 + this patch series
> @hugetlb_add_to_page_cache:
> [512, 1K) 6345 |@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@|
> [1K, 2K) 1308 |@@@@@@@@@@ |
> [2K, 4K) 39 | |
> [4K, 8K) 20 | |
> [8K, 16K) 8 | |
> [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.5.0-rc1 + this patch series
> @__filemap_get_folio:
> @get_folio_ns:
> [128, 256) 13 | |
> [256, 512) 11131 |@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@|
> [512, 1K) 5544 |@@@@@@@@@@@@@@@@@@@@@@@@@ |
> [1K, 2K) 996 |@@@@ |
> [2K, 4K) 317 |@ |
> [4K, 8K) 76 | |
> [8K, 16K) 23 | |
> [16K, 32K) 6 | |
> [32K, 64K) 1 | |
> [64K, 128K) 0 | |
> [128K, 256K) 0 | |
> [256K, 512K) 0 | |
> [512K, 1M) 0 | |
> [1M, 2M) 0 | |
> [2M, 4M) 0 | |
> [4M, 8M) 0 | |
> [8M, 16M) 0 | |
> [16M, 32M) 0 | |
> [32M, 64M) 0 | |
> [64M, 128M) 0 | |
> [128M, 256M) 0 | |
> [256M, 512M) 0 | |
> [512M, 1G) 0 | |
> [1G, 2G) 0 | |
> [2G, 4G) 3 |
>
> =========================== TESTING ==========================================
> This series passes the LTP hugetlb test cases as well as the libhugetlbfs tests.
>
> ********** TEST SUMMARY
> * 2M
> * 32-bit 64-bit
> * Total testcases: 110 113
> * Skipped: 0 0
> * PASS: 107 113
> * FAIL: 0 0
> * Killed by signal: 3 0
> * Bad configuration: 0 0
> * Expected FAIL: 0 0
> * Unexpected PASS: 0 0
> * Test not present: 0 0
> * Strange test result: 0 0
> **********
>
>
>
> 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.
>
> v1 -> v2
> - squash seperate filemap and hugetlb patches into one to allow for bisection
> per Matthew
> - get rid of page_to_index()
> - fix errors in hugetlb_fallocate() and remove_inode_hugepages()
>
>
> rebased on 07/10/2023 mm-unstable
>
>
> Sidhartha Kumar (1):
> mm/filemap: remove hugetlb special casing in filemap.c
>
> fs/hugetlbfs/inode.c | 10 +++++-----
> include/linux/hugetlb.h | 12 ++++++++++++
> include/linux/pagemap.h | 26 ++------------------------
> mm/filemap.c | 36 +++++++++++-------------------------
> mm/hugetlb.c | 11 ++++++-----
> 5 files changed, 36 insertions(+), 59 deletions(-)
>
> --
> 2.41.0
>
next prev parent reply other threads:[~2023-07-20 0:00 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-07-10 23:04 [PATCH v2 0/1] change ->index to PAGE_SIZE for hugetlb pages Sidhartha Kumar
2023-07-10 23:04 ` [PATCH v2 1/1] mm/filemap: remove hugetlb special casing in filemap.c Sidhartha Kumar
2023-07-11 19:32 ` Andrew Morton
2023-07-21 20:22 ` Mike Kravetz
2023-07-20 0:00 ` Mike Kravetz [this message]
2023-07-22 4:05 ` [PATCH v2 0/1] change ->index to PAGE_SIZE for hugetlb pages 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=20230720000011.GD3240@monkey \
--to=mike.kravetz@oracle.com \
--cc=akpm@linux-foundation.org \
--cc=david@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=sidhartha.kumar@oracle.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 NNTP newsgroup(s).