ng
> - Preserve RMAP_EXCLUSIVE semantics for anonymous exclusive folios
> - Skip RMP_USE_SHARED_ZEROPAGE for device-private entries as they
> don't support shared zero page semantics
>
> Signed-off-by: Balbir Singh
> Cc: David Hildenbrand
> Cc: Zi Yan
> Cc: Joshua Hahn
t; Reviewed-by: SeongJae Park
> Cc: David Hildenbrand
> Cc: Zi Yan
> Cc: Joshua Hahn
> Cc: Rakie Kim
> Cc: Byungchul Park
> Cc: Gregory Price
> Cc: Ying Huang
> Cc: Alistair Popple
> Cc: Oscar Salvador
> Cc: Lorenzo Stoakes
> Cc: Baolin Wang
> Cc: "
On 19 Sep 2025, at 1:01, Balbir Singh wrote:
> On 9/18/25 12:49, Zi Yan wrote:
>> On 16 Sep 2025, at 8:21, Balbir Singh wrote:
>>
>>> Add routines to support allocation of large order zone device folios
>>> and helper functions for zone device folios, to check if
tthew Brost
> Signed-off-by: Balbir Singh
> Cc: David Hildenbrand
> Cc: Zi Yan
> Cc: Joshua Hahn
> Cc: Rakie Kim
> Cc: Byungchul Park
> Cc: Gregory Price
> Cc: Ying Huang
> Cc: Alistair Popple
> Cc: Oscar Salvador
> Cc: Lorenzo Stoakes
> Cc: Baolin W
d, the existing page_free() callback in
> pgmap is called when the folio is freed, this is true for both
> PAGE_SIZE and higher order pages.
>
> Zone device private large folios do not support deferred split and
> scan like normal THP folios.
>
> Signed-off-by: Balbir Singh
> Cc
On 27 Aug 2025, at 18:01, David Hildenbrand wrote:
> Let's cleanup and simplify the function a bit.
>
> Signed-off-by: David Hildenbrand
> ---
> fs/hugetlbfs/inode.c | 33 +++--
> 1 file changed, 11 insertions(+), 22 deletions(-)
>
LGTM. Rev
1 insertion(+), 1 deletion(-)
>
LGTM. Reviewed-by: Zi Yan
--
Best Regards,
Yan, Zi
ther SPARSEMEM without SPARSEMEM_VMEMMAP cannot be configured or
> gigantic folios will not exceed a memory section (the case on sparse).
>
> Signed-off-by: David Hildenbrand
> ---
> mm/hugetlb.c | 2 ++
> 1 file changed, 2 insertions(+)
>
LGTM. Reviewed-by: Zi Yan
--
Best Regards,
Yan, Zi
a folio.
+ * @folio: The folio.
+ * @n: Page index within the folio.
+ *
+ * This function expects that n does not exceed folio_nr_pages(folio).
+ * The returned page is relative to the first page of the folio.
+ */
>
> static __always_inline int PageTail(const struct page *page)
> {
> --
> 2.50.1
Otherwise, Reviewed-by: Zi Yan
Best Regards,
Yan, Zi
n that.
>
> Signed-off-by: David Hildenbrand
> ---
> include/linux/mm.h | 6 --
> mm/page_alloc.c| 5 -
> 2 files changed, 8 insertions(+), 3 deletions(-)
>
LGTM. Reviewed-by: Zi Yan
Best Regards,
Yan, Zi
On 21 Aug 2025, at 16:49, David Hildenbrand wrote:
> On 21.08.25 22:46, Zi Yan wrote:
>> On 21 Aug 2025, at 16:06, David Hildenbrand wrote:
>>
>>> Let's limit the maximum folio size in problematic kernel config where
>>> the memmap is allocated
> + */
> +#define MAX_FOLIO_ORDER PFN_SECTION_SHIFT
> +#else
> +/*
> + * There is no real limit on the folio size. We limit them to the maximum we
> + * currently expect.
The comment about hugetlbfs is helpful here, since the other folios are still
limited by buddy allocator’s MAX
ialized
> through prepare_compound_head() / prepare_compound_page().
>
> Signed-off-by: David Hildenbrand
> ---
> mm/internal.h | 1 +
> 1 file changed, 1 insertion(+)
>
Reviewed-by: Zi Yan
Best Regards,
Yan, Zi
ti
> Cc: "David S. Miller"
> Cc: Andreas Larsson
> Signed-off-by: David Hildenbrand
> ---
> mm/Kconfig | 3 +--
> 1 file changed, 1 insertion(+), 2 deletions(-)
>
Acked-by: Zi Yan
Best Regards,
Yan, Zi
On 8 Jul 2025, at 10:38, David Hildenbrand wrote:
> On 06.03.25 05:42, Balbir Singh wrote:
>> Support splitting pages during THP zone device migration as needed.
>> The common case that arises is that after setup, during migrate
>> the destination might not be able to allocate MIGRATE_PFN_COMPOUND
changes for us to give it a try? That is, do I need to include any other
>>> code from the list to test this out?
>>>
>>
>> Thank you, the patches are built on top of mm-everything-2025-03-04-05-51,
>> which
>> includes changes by Alistair to fix fs/da
le pools */
"GPU pages" seems confusing. These are not pages from GPU memory, right?
Would the comments below sound better?
/* Pages assigned to a GPU object */
/* Pages in shrinkable GPU pools */
Otherwise, Acked-by: Zi Yan
--
Best Regards,
Yan, Zi
mm/migrate.c | 60 ++--
> 1 file changed, 7 insertions(+), 53 deletions(-)
>
LGTM. Reviewed-by: Zi Yan
--
Best Regards,
Yan, Zi
On 6 Aug 2021, at 5:37, Christian König wrote:
> Am 05.08.21 um 21:58 schrieb Zi Yan:
>> On 5 Aug 2021, at 15:16, Christian König wrote:
>>
>>> Am 05.08.21 um 21:02 schrieb Zi Yan:
>>>> From: Zi Yan
>>>>
>>>> This prepares for the u
From: Zi Yan
This prepares for the upcoming changes to make MAX_ORDER a boot time
parameter instead of compilation time constant. All static arrays with
MAX_ORDER size are converted to pointers and their memory is allocated
at runtime.
free_area array in struct zone is allocated using
On 5 Aug 2021, at 15:16, Christian König wrote:
> Am 05.08.21 um 21:02 schrieb Zi Yan:
>> From: Zi Yan
>>
>> This prepares for the upcoming changes to make MAX_ORDER a boot time
>> parameter instead of compilation time constant. All static arrays with
>> MAX_ORD
On 26 Feb 2021, at 2:18, Alistair Popple wrote:
> Migration is currently implemented as a mode of operation for
> try_to_unmap_one() generally specified by passing the TTU_MIGRATION flag
> or in the case of splitting a huge anonymous page TTU_SPLIT_FREEZE.
>
> However it does not have much in comm
22 matches
Mail list logo
