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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.