| lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
|
Open Source and information security mailing list archives
| ||
|
Message-ID: <20230720000011.GD3240@monkey>
Date: Wed, 19 Jul 2023 17:00:11 -0700
From: Mike Kravetz <mike.kravetz@...cle.com>
To: Sidhartha Kumar <sidhartha.kumar@...cle.com>
Cc: linux-kernel@...r.kernel.org, linux-mm@...ck.org,
akpm@...ux-foundation.org, willy@...radead.org,
songmuchun@...edance.com, david@...hat.com
Subject: Re: [PATCH v2 0/1] change ->index to PAGE_SIZE for hugetlb pages
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
>
Powered by blists - more mailing lists