From: Zi Yan
In isolate_migratepages_block, if we have too many isolated pages and
nr_migratepages is not zero, we should try to migrate what we have
without wasting time on isolating.
Fixes: 1da2f328fa64 (“mm,thp,compaction,cma: allow THP migration for CMA
allocations”)
Suggested
On 30 Oct 2020, at 10:50, Vlastimil Babka wrote:
> On 10/29/20 9:04 PM, Zi Yan wrote:
>> From: Zi Yan
>>
>> In isolate_migratepages_block, when cc->alloc_contig is true, we are
>> able to isolate compound pages, nr_migratepages and nr_isolated did not
>> cou
On 30 Oct 2020, at 10:49, Michal Hocko wrote:
> On Fri 30-10-20 10:35:43, Zi Yan wrote:
>> On 30 Oct 2020, at 9:36, Michal Hocko wrote:
>>
>>> On Fri 30-10-20 08:20:50, Zi Yan wrote:
>>>> On 30 Oct 2020, at 5:43, Michal Hocko wrote:
>>>>
>>&
On 30 Oct 2020, at 9:36, Michal Hocko wrote:
> On Fri 30-10-20 08:20:50, Zi Yan wrote:
>> On 30 Oct 2020, at 5:43, Michal Hocko wrote:
>>
>>> [Cc Vlastimil]
>>>
>>> On Thu 29-10-20 16:04:35, Zi Yan wrote:
>>>> From: Zi Yan
>>>>
On 30 Oct 2020, at 5:43, Michal Hocko wrote:
> [Cc Vlastimil]
>
> On Thu 29-10-20 16:04:35, Zi Yan wrote:
>> From: Zi Yan
>>
>> In isolate_migratepages_block, when cc->alloc_contig is true, we are
>> able to isolate compound pages, nr_migratepages and nr_isol
On 29 Oct 2020, at 20:28, Andrew Morton wrote:
> On Thu, 29 Oct 2020 17:31:28 -0400 Zi Yan wrote:
>
>>>
>>> Shall you add Fixes tag to commit
>>> 1da2f328fa643bd72197dfed0c655148af31e4eb? And may cc stable.
>>
>> Sure.
>>
>> Fixes:
On 29 Oct 2020, at 17:14, Yang Shi wrote:
> On Thu, Oct 29, 2020 at 1:04 PM Zi Yan wrote:
>>
>> From: Zi Yan
>>
>> In isolate_migratepages_block, when cc->alloc_contig is true, we are
>> able to isolate compound pages, nr_migratepages and nr_isolated did n
From: Zi Yan
In isolate_migratepages_block, when cc->alloc_contig is true, we are
able to isolate compound pages, nr_migratepages and nr_isolated did not
count compound pages correctly, causing us to isolate more pages than we
thought. Use thp_nr_pages to count pages. Otherwise, we mi
On 22 Oct 2020, at 20:47, Roman Gushchin wrote:
> On Thu, Oct 22, 2020 at 07:42:45PM -0400, Zi Yan wrote:
>> On 22 Oct 2020, at 18:53, Roman Gushchin wrote:
>>
>>> This small patchset introduces a non-blocking version of cma_release()
>>> and simplifies the code
On 22 Oct 2020, at 18:53, Roman Gushchin wrote:
> This small patchset introduces a non-blocking version of cma_release()
> and simplifies the code in hugetlbfs, where previously we had to
> temporarily drop hugetlb_lock around the cma_release() call.
>
> It should help Zi Yan on h
On 5 Oct 2020, at 11:55, Matthew Wilcox wrote:
> On Mon, Oct 05, 2020 at 11:03:56AM -0400, Zi Yan wrote:
>> On 2 Oct 2020, at 4:30, David Hildenbrand wrote:
>>> Yes, I think one important feature would be that we don't end up placing
>>> a gigantic page where only a ha
On 5 Oct 2020, at 13:39, David Hildenbrand wrote:
consideting that 2MB THP have turned out to be quite a pain but
situation has settled over time. Maybe our current code base is prepared
for that much better.
>>
>> I am planning to refactor my code further to reduce the amount of
On 2 Oct 2020, at 3:50, David Hildenbrand wrote:
- huge page sizes controllable by the userspace?
>>>
>>> It might be good to allow advanced users to choose the page sizes, so they
>>> have better control of their applications.
>>
>> Could you elaborate more? Those advanced users can use
On 2 Oct 2020, at 4:30, David Hildenbrand wrote:
> On 02.10.20 10:10, Michal Hocko wrote:
>> On Fri 02-10-20 09:50:02, David Hildenbrand wrote:
>> - huge page sizes controllable by the userspace?
>
> It might be good to allow advanced users to choose the page sizes, so they
> have
On 30 Sep 2020, at 7:55, Michal Hocko wrote:
> On Mon 28-09-20 13:53:58, Zi Yan wrote:
>> From: Zi Yan
>>
>> Hi all,
>>
>> This patchset adds support for 1GB PUD THP on x86_64. It is on top of
>> v5.9-rc5-mmots-2020-09-18-21-23. It is also available at:
&g
On 28 Sep 2020, at 15:34, Matthew Wilcox wrote:
> On Mon, Sep 28, 2020 at 01:54:01PM -0400, Zi Yan wrote:
>> struct {/* Page table pages */
>> -unsigned long _pt_pad_1;/* compound_head */
>> -pgtable_t pmd_h
From: Zi Yan
It allows user to specify up to what page size kernel will generate THPs
to back up the memory range in madvise. Because we now have PMD and PUD
THPs, they require different amount of kernel effort to be generated,
and we want to prevent user from getting long page fault latency
From: Zi Yan
Signed-off-by: Zi Yan
---
fs/proc/task_mmu.c | 68 ++
1 file changed, 63 insertions(+), 5 deletions(-)
diff --git a/fs/proc/task_mmu.c b/fs/proc/task_mmu.c
index a21484b1414d..077196182288 100644
--- a/fs/proc/task_mmu.c
+++ b/fs/proc
From: Zi Yan
Like the existing global PMD THP knob, it allows user to enable/disable
PUD THPs. PUD THP is disabled by default unless user knows the
performance tradeoff of using it, like longer first time page fault
due to larger page zeroing and longer page allocation time when memory
From: Zi Yan
Bit 27 is used to identify PUD THP.
Signed-off-by: Zi Yan
---
fs/proc/page.c | 2 ++
include/uapi/linux/kernel-page-flags.h | 1 +
2 files changed, 3 insertions(+)
diff --git a/fs/proc/page.c b/fs/proc/page.c
index f3b39a7d2bf3..e4e2ad3612c9 100644
From: Zi Yan
Hi all,
This patchset adds support for 1GB PUD THP on x86_64. It is on top of
v5.9-rc5-mmots-2020-09-18-21-23. It is also available at:
https://github.com/x-y-z/linux-1gb-thp/tree/1gb_thp_v5.9-rc5-mmots-2020-09-18-21-23
Other than PUD THP, we had some discussion on generating THPs
From: Zi Yan
When PMD-mapped PUD THP is enabled by the upcoming commits, we can unmap
a PMD-mapped PUD THP that should be counted as NR_ANON_THPS. The added
map_order tells us about this situation.
Signed-off-by: Zi Yan
---
mm/rmap.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions
From: Zi Yan
copy_huge_pud needs to allocate 1 PMD page table page and 512 PTE page
table pages and deposit them when copying a PUD THP. It is similar to
what we do at PUD THP page faults.
Signed-off-by: Zi Yan
---
mm/huge_memory.c | 36
1 file changed, 28
From: Zi Yan
pagemap_pud_range is added to print pud page flags properly.
Signed-off-by: Zi Yan
---
fs/proc/task_mmu.c | 63 ++
1 file changed, 63 insertions(+)
diff --git a/fs/proc/task_mmu.c b/fs/proc/task_mmu.c
index 077196182288..04a3158d0d5b
From: Zi Yan
It will be used by other allocations, like 1GB THP allocation in the
upcoming commit.
Signed-off-by: Zi Yan
---
.../admin-guide/kernel-parameters.txt | 2 +-
arch/arm64/mm/hugetlbpage.c | 2 +-
arch/powerpc/mm/hugetlbpage.c | 2
From: Zi Yan
We now have PMD-mapped PUD THP and PTE-mapped PUD THP, page_vma_walk
should handle them properly.
Signed-off-by: Zi Yan
---
mm/page_vma_mapped.c | 152 +--
1 file changed, 118 insertions(+), 34 deletions(-)
diff --git a/mm
From: Zi Yan
We cannot swap PUD THPs, so split them before swap them out. PUD THPs
will be split into PMD THPs, so that if THP_SWAP is enabled, PMD THPs
can be swapped out as a whole.
Signed-off-by: Zi Yan
---
mm/swap_slots.c | 2 ++
mm/vmscan.c | 33 +++--
2
From: Zi Yan
All previous commits have anonymous PUD THP support ready, so we can
enable anonymous PUD THP page fault now.
Signed-off-by: Zi Yan
---
mm/memory.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/mm/memory.c b/mm/memory.c
index 9f7b509a3aa7..dc285d9872fc
From: Zi Yan
When PUD mapping is gone, there is no need to keep the PUD THP. Add it
to deferred split list, so when memory pressure comes, the THP will be
split.
Signed-off-by: Zi Yan
---
mm/rmap.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/mm/rmap.c b/mm/rmap.c
index b4950f7a0978
From: Zi Yan
Add follow_page support for PUD THPs.
Signed-off-by: Zi Yan
---
include/linux/huge_mm.h | 11 +++
mm/gup.c| 60 -
mm/huge_memory.c| 73 -
3 files changed, 142 insertions(+), 2
From: Zi Yan
Add PUD-level TLB flush ops and teach page_vma_mapped_talk about PUD
THPs.
Signed-off-by: Zi Yan
---
arch/x86/include/asm/pgtable.h | 3 +++
arch/x86/mm/pgtable.c | 13 +
include/linux/mmu_notifier.h | 13 +
include/linux/pgtable.h| 14
From: Jason Gunthorpe
The pagewalker runs while only holding the mmap_sem for read. The pud can
be set asynchronously, while also holding the mmap_sem for read
eg from:
handle_mm_fault()
__handle_mm_fault()
create_huge_pmd()
dev_dax_huge_fault()
__dev_dax_pud_fault()
From: Zi Yan
madvise can set this bit via MADV_HUGEPAGE | MADV_HUGEPAGE_1GB and unset
it via MADV_NOHUGEPAGE | MADV_HUGEPAGE_1GB. Later, kernel will check
this bit to decide whether to allocate PUD THPs or not on a VMA when the
global PUD THP is set to madvise.
Signed-off-by: Zi Yan
From: Zi Yan
We deposit 512 PMD pages, each of which has 512 PTE pages deposited in
its ->deposit_head, to mm->deposit_head_pud. They will be withdrawn and
used when a PUD THP split into 512 PMD THPs. In this way, when any of
the 512 PMD THPs is split further, we will use the existing cod
From: Zi Yan
It mimics PMD-level THP split. In addition, to support PMD-mapped PUD
THP, PMDPageInPUD() is added to identify the first page in the PMD sized
aligned physical pages. For example, in x86_64, the page[0], page[512],
page[1024], ... are regarded as PMDPageInPUD.
For the mapcount
From: Zi Yan
COW on PUD THPs has the same behavior as COW on PMD THPs to avoid high
COW overhead. As a result, do_huge_pmd_wp will see PMD-mapped PUD THPs,
thus needs to count PUD mappings in total mapcount when calling
page_trans_huge_map_swapcount in reuse_swap_page to avoid false positive
From: Zi Yan
Preallocated 513 (1 PMD and 512 PTE) page table pages need to be freed
when PUD THP is removed. zap_pud_deposited_table is added to perform the
action.
Signed-off-by: Zi Yan
---
mm/huge_memory.c | 48 +---
1 file changed, 45 insertions
From: Zi Yan
The old design uses the double linked list page->lru to chain all
deposited page table pages when creating a THP and page->pmd_huge_pte
to point to the first page of the list. As the second pointer in
page->lru overlaps with page->pmd_huge_pte, the design prevents
mult
From: Zi Yan
User can access the PUD THP size via
`cat /sys/kernel/mm/transparent_hugepage/hpage_pud_size`. This is
similar to make PMD THP size public.
Signed-off-by: Zi Yan
---
Documentation/admin-guide/mm/transhuge.rst | 1 +
mm/huge_memory.c | 13
From: Zi Yan
This prepares for PUD THP support, which allocates 512 of such PMD pages
when creating a PUD THP. These page table pages will be withdrawn during
THP split.
Signed-off-by: Zi Yan
---
arch/x86/include/asm/pgalloc.h | 60 ++
arch/x86/mm/pgtable.c
From: Zi Yan
Since the order of a PUD THP is greater than MAX_ORDER, do not consider
its tail pages corrupted. Also print sub_compound_mapcount when dumping
a PMDPageInPUD.
Signed-off-by: Zi Yan
---
mm/debug.c | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/mm/debug.c
From: Zi Yan
The pagewalker runs while only holding the mmap_sem for read. The pud can
be set asynchronously, while also holding the mmap_sem for read.
This follows the same way as the commit:
mm/pagewalk: use READ_ONCE when reading the PUD entry unlocked"
Signed-off-by: Zi Yan
---
fs
From: Zi Yan
As PUD THP is going to be added in the following patches, thp_order and
thp_nr can be HPAGE_PUD_ORDER and HPAGE_PUD_NR, respectively.
Signed-off-by: Zi Yan
---
include/linux/huge_mm.h | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/include/linux/huge_mm.h
From: Zi Yan
Sharing hugepage_cma reservation with hugetlb for pud thp allocaiton.
The reserved cma regions still can be used for moveable page allocations.
During 1GB page split, all subpages are cleared from the CMA bitmap,
since they are no more 1GB pages and will be freed via the normal
From: Zi Yan
page_add_anon_rmap, do_page_add_anon_rmap, page_add_new_anon_rmap,
page_remove_rmap are changed to have page order as a parameter. This
prepares for PMD-mapped PUD THP, since a PUD THP can be mapped in three
different ways, PTEs, PMDs, and PUDs and the original boolean parameter
From: Zi Yan
Unmap different subpages in different sized THPs properly in the
try_to_unmap() function. pvmw.pte, pvmw.pmd, pvmw.pud are used to
identify unmapped page sizes:
1. pvmw.pte != NULL: PTE pages or PageHuge.
2. pvmw.pte == NULL and pvmw.pmd != NULL: PMD pages.
3. pvmw.pte == NULL
From: Zi Yan
This adds PUD THP support for anonymous pages. Applications will be
able to get PUD pages during page faults when their VMAs are larger than
PUD page size after the page fault path is enabled.
No shared zero PUD THP is created and shared by all read-only zero PUD
THPs, different
bool move_huge_pmd(struct vm_area_struct *vma, unsigned long old_addr,
>unsigned long new_addr,
>pmd_t *old_pmd, pmd_t *new_pmd);
> --
> 2.17.1
LGTM. Reviewed-by: Zi Yan
Thanks.
—
Best Regards,
Yan Zi
signature.asc
Description: OpenPGP digital signature
From: Zi Yan
PageTransHuge returns true for both thp and hugetlb, so thp stats was
counting both thp and hugetlb migrations. Exclude hugetlb migration by
setting is_thp variable right.
Clean up thp handling code too when we are there.
Fixes: 1a5bae25e3cf ("mm/vmstat: add events fo
On 17 Sep 2020, at 16:59, Daniel Jordan wrote:
> On Thu, Sep 17, 2020 at 04:27:29PM -0400, Zi Yan wrote:
>> From: Zi Yan
>>
>> PageTransHuge returns true for both thp and hugetlb, so thp stats was
>> counting both thp and hugetlb migrations. Exclude hugetlb mig
From: Zi Yan
PageTransHuge returns true for both thp and hugetlb, so thp stats was
counting both thp and hugetlb migrations. Exclude hugetlb migration by
setting is_thp variable right.
Fixes: 1a5bae25e3cf ("mm/vmstat: add events for THP migration without split")
Signed-off-by:
On 10 Sep 2020, at 4:27, David Hildenbrand wrote:
> On 10.09.20 09:32, Michal Hocko wrote:
>> [Cc Vlastimil and Mel - the whole email thread starts
>> http://lkml.kernel.org/r/20200902180628.4052244-1-zi@sent.com
>> but this particular subthread has diverged a bit and you might find it
>>
On 10 Sep 2020, at 9:32, Rik van Riel wrote:
> On Thu, 2020-09-10 at 09:32 +0200, Michal Hocko wrote:
>> [Cc Vlastimil and Mel - the whole email thread starts
>> http://lkml.kernel.org/r/20200902180628.4052244-1-zi@sent.com
>> but this particular subthread has diverged a bit and you might
On 10 Sep 2020, at 10:34, David Hildenbrand wrote:
>>> As long as we stay in safe zone boundaries you get a benefit in most
>>> scenarios. As soon as we would have a (temporary) workload that would
>>> require more unmovable allocations we would fallback to polluting some
>>> pageblocks only.
>>
On 9 Sep 2020, at 10:18, Kirill A. Shutemov wrote:
> On Wed, Sep 02, 2020 at 02:06:18PM -0400, Zi Yan wrote:
>> 25 files changed, 852 insertions(+), 98 deletions(-)
>
> It's way too big to have meaningful review.
Will split it into small patches in the next version.
—
Best
On 9 Sep 2020, at 9:46, Kirill A. Shutemov wrote:
> On Mon, Sep 07, 2020 at 11:11:05AM -0400, Zi Yan wrote:
>> On 7 Sep 2020, at 8:22, Kirill A. Shutemov wrote:
>>
>>> On Wed, Sep 02, 2020 at 02:06:13PM -0400, Zi Yan wrote:
>>>> From: Zi Yan
>>>&g
On 9 Sep 2020, at 10:09, Kirill A. Shutemov wrote:
> On Wed, Sep 02, 2020 at 02:06:17PM -0400, Zi Yan wrote:
>> From: Zi Yan
>>
>> Add PUD-level TLB flush ops and teach page_vma_mapped_talk about 1GB
>> THPs.
>>
>> Signed-off-by: Zi Yan
>>
On 7 Sep 2020, at 3:20, Michal Hocko wrote:
> On Fri 04-09-20 14:10:45, Roman Gushchin wrote:
>> On Fri, Sep 04, 2020 at 09:42:07AM +0200, Michal Hocko wrote:
> [...]
>>> An explicit opt-in sounds much more appropriate to me as well. If we go
>>> with a specific API then I would not make it 1GB
On 8 Sep 2020, at 10:22, David Hildenbrand wrote:
> On 08.09.20 16:05, Zi Yan wrote:
>> On 8 Sep 2020, at 7:57, David Hildenbrand wrote:
>>
>>> On 03.09.20 18:30, Roman Gushchin wrote:
>>>> On Thu, Sep 03, 2020 at 05:23:00PM +0300, Kirill A. Shutemov wrote:
On 8 Sep 2020, at 10:27, Matthew Wilcox wrote:
> On Tue, Sep 08, 2020 at 10:05:11AM -0400, Zi Yan wrote:
>> On 8 Sep 2020, at 7:57, David Hildenbrand wrote:
>>> I have concerns if we would silently use 1~GB THPs in most scenarios
>>> where be would have used 2~MB TH
On 8 Sep 2020, at 7:57, David Hildenbrand wrote:
> On 03.09.20 18:30, Roman Gushchin wrote:
>> On Thu, Sep 03, 2020 at 05:23:00PM +0300, Kirill A. Shutemov wrote:
>>> On Wed, Sep 02, 2020 at 02:06:12PM -0400, Zi Yan wrote:
>>>> From: Zi Yan
>>>>
>>
On 7 Sep 2020, at 8:22, Kirill A. Shutemov wrote:
> On Wed, Sep 02, 2020 at 02:06:13PM -0400, Zi Yan wrote:
>> From: Zi Yan
>>
>> When depositing page table pages for 1GB THPs, we need 512 PTE pages +
>> 1 PMD page. Instead of counting and depositing 513 pages,
MD entry is a migration PMD entry, the call to
> is_huge_zero_pmd(*pmd) is incorrect because it calls pmd_pfn(pmd) instead
> of migration_entry_to_pfn(pmd_to_swp_entry(pmd)).
> Fix these problems by checking for a PMD migration entry.
>
> Signed-off-by: Ralph Campbell
Thanks for th
On 2 Sep 2020, at 16:29, Randy Dunlap wrote:
> On 9/2/20 11:06 AM, Zi Yan wrote:
>> From: Zi Yan
>>
>> When depositing page table pages for 1GB THPs, we need 512 PTE pages +
>> 1 PMD page. Instead of counting and depositing 513 pages, we can use the
>> PM
On 2 Sep 2020, at 15:57, Jason Gunthorpe wrote:
> On Wed, Sep 02, 2020 at 03:05:39PM -0400, Zi Yan wrote:
>> On 2 Sep 2020, at 14:48, Jason Gunthorpe wrote:
>>
>>> On Wed, Sep 02, 2020 at 02:45:37PM -0400, Zi Yan wrote:
>>>
>>>>> Surprised this does
On 2 Sep 2020, at 14:48, Jason Gunthorpe wrote:
> On Wed, Sep 02, 2020 at 02:45:37PM -0400, Zi Yan wrote:
>
>>> Surprised this doesn't touch mm/pagewalk.c ?
>>
>> 1GB PUD page support is present for DAX purpose, so the code is there
>> in mm/pagewalk.c alr
On 2 Sep 2020, at 14:40, Jason Gunthorpe wrote:
> On Wed, Sep 02, 2020 at 02:06:12PM -0400, Zi Yan wrote:
>> From: Zi Yan
>>
>> Hi all,
>>
>> This patchset adds support for 1GB THP on x86_64. It is on top of
>> v5.9-rc2-mmots-2020-08-25-21-13.
>
From: Zi Yan
Signed-off-by: Zi Yan
---
fs/proc/task_mmu.c | 63 ++
1 file changed, 58 insertions(+), 5 deletions(-)
diff --git a/fs/proc/task_mmu.c b/fs/proc/task_mmu.c
index 7fc9b3cc48d3..2ff80a9c8b57 100644
--- a/fs/proc/task_mmu.c
+++ b/fs/proc
From: Zi Yan
Add follow_page support for 1GB THPs.
Signed-off-by: Zi Yan
---
include/linux/huge_mm.h | 11 +++
mm/gup.c| 60 -
mm/huge_memory.c| 73 -
3 files changed, 142 insertions(+), 2
From: Zi Yan
Unmap different subpages in different sized THPs properly in the
try_to_unmap() function.
Signed-off-by: Zi Yan
---
mm/migrate.c | 2 +-
mm/rmap.c| 159 +--
2 files changed, 116 insertions(+), 45 deletions(-)
diff --git a/mm
From: Zi Yan
Print page flags properly.
Signed-off-by: Zi Yan
---
fs/proc/task_mmu.c | 59 ++
1 file changed, 59 insertions(+)
diff --git a/fs/proc/task_mmu.c b/fs/proc/task_mmu.c
index 2ff80a9c8b57..7254c7ecf659 100644
--- a/fs/proc/task_mmu.c
From: Zi Yan
Use alloc_contig_pages for allocation and destroy_compound_gigantic_page
for deallocation, so 1GB THP can be created and destroyed without
changing MAX_ORDER.
Signed-off-by: Zi Yan
---
mm/hugetlb.c| 22 --
mm/internal.h | 2 ++
mm/mempolicy.c | 15
From: Zi Yan
It does not affect existing 1GB THPs. It is similar to the knob for
2MB THPs.
Signed-off-by: Zi Yan
---
include/linux/huge_mm.h | 14 ++
mm/huge_memory.c| 40
mm/memory.c | 2 +-
3 files changed, 55
From: Zi Yan
It mimics PMD-level THP split. In addition, to support PMD-mapped PUD
THP, PMDPageInPUD() is used. For the mapcount of PMD-mapped PUD THP,
sub_compound_mapcount() is used, which uses
(head_page+3).compound_mapcount, since each base page's mapcount is used
for PTE mapping
From: Zi Yan
Sharing hugepage_cma reservation with hugetlb for pud thp allocaiton.
The reserved cma regions still can be used for moveable page allocations.
During 1GB page split, all subpages are cleared from the CMA bitmap,
since they are no more 1GB pages and will be freed via the normal
From: Zi Yan
It will be used by other allocations, like 1GB THP allocation in the
upcoming commit.
Signed-off-by: Zi Yan
---
.../admin-guide/kernel-parameters.txt | 2 +-
arch/arm64/mm/hugetlbpage.c | 2 +-
arch/powerpc/mm/hugetlbpage.c | 2
From: Zi Yan
Add PUD-level TLB flush ops and teach page_vma_mapped_talk about 1GB
THPs.
Signed-off-by: Zi Yan
---
arch/x86/include/asm/pgtable.h | 3 +++
arch/x86/mm/pgtable.c | 13 +
include/linux/mmu_notifier.h | 13 +
include/linux/pgtable.h| 14
From: Zi Yan
We now have PMD-mapped PUD THP and PTE-mapped PUD THP, page_vma_walk
should handle them properly.
Signed-off-by: Zi Yan
---
mm/page_vma_mapped.c | 116 ++-
1 file changed, 82 insertions(+), 34 deletions(-)
diff --git a/mm/page_vma_mapped.c
From: Zi Yan
We cannot swap 1GB THPs, so split them before swap them out.
Signed-off-by: Zi Yan
---
mm/swap_slots.c | 2 ++
mm/vmscan.c | 58 +
2 files changed, 46 insertions(+), 14 deletions(-)
diff --git a/mm/swap_slots.c b/mm
From: Zi Yan
Hi all,
This patchset adds support for 1GB THP on x86_64. It is on top of
v5.9-rc2-mmots-2020-08-25-21-13.
1GB THP is more flexible for reducing translation overhead and increasing the
performance of applications with large memory footprint without application
changes compared
From: Zi Yan
This adds 1GB THP support for anonymous pages. Applications can get 1GB
pages during page faults when their VMAs are larger than 1GB. For
read-only 1GB zero THP, a shared 1GB zero THP is created for all
readers.
Signed-off-by: Zi Yan
---
arch/x86/include/asm/pgalloc.h | 59
From: Zi Yan
When depositing page table pages for 1GB THPs, we need 512 PTE pages +
1 PMD page. Instead of counting and depositing 513 pages, we can use the
PMD page as a leader page and chain the rest 512 PTE pages with ->lru.
This, however, prevents us depositing PMD pages with ->lru,
From: Zi Yan
COW on 1GB THPs will fall back to 2MB THPs if 1GB THP is not available.
Signed-off-by: Zi Yan
---
arch/x86/include/asm/pgalloc.h | 9 ++
include/linux/huge_mm.h| 5
mm/huge_memory.c | 54 ++
mm/memory.c
From: Zi Yan
Bit 27 is used to identify 1GB THP.
Signed-off-by: Zi Yan
---
fs/proc/page.c | 2 ++
include/uapi/linux/kernel-page-flags.h | 2 ++
2 files changed, 4 insertions(+)
diff --git a/fs/proc/page.c b/fs/proc/page.c
index f3b39a7d2bf3..e4e2ad3612c9 100644
On 9 Jul 2020, at 12:39, Randy Dunlap wrote:
> On 7/9/20 9:34 AM, Zi Yan wrote:
>> On 9 Jul 2020, at 11:34, Randy Dunlap wrote:
>>
>>> Hi,
>>>
>>> I have a few comments on this.
>>>
>>> a. I reported it very early and should have been C
On 9 Jul 2020, at 11:34, Randy Dunlap wrote:
> Hi,
>
> I have a few comments on this.
>
> a. I reported it very early and should have been Cc-ed.
>
> b. A patch that applies to mmotm or linux-next would have been better
> than a full replacement patch.
>
> c. I tried replacing what I believe is
On 30 Jun 2020, at 15:31, Dave Hansen wrote:
>
>
>> BTW is this proposal only for systems having multi-tiers of memory?
>> Can a multi-node DRAM-only system take advantage of this proposal? For
>> example I have a system with two DRAM nodes running two jobs
>> hardwalled to each node. For each
On 22 Jun 2020, at 17:31, Ralph Campbell wrote:
> On 6/22/20 1:10 PM, Zi Yan wrote:
>> On 22 Jun 2020, at 15:36, Ralph Campbell wrote:
>>
>>> On 6/21/20 4:20 PM, Zi Yan wrote:
>>>> On 19 Jun 2020, at 17:56, Ralph Campbell wrote:
>>>>
>>>
On 22 Jun 2020, at 15:36, Ralph Campbell wrote:
> On 6/21/20 4:20 PM, Zi Yan wrote:
>> On 19 Jun 2020, at 17:56, Ralph Campbell wrote:
>>
>>> Support transparent huge page migration to ZONE_DEVICE private memory.
>>> A new flag (MIGRATE_PFN_COMPOUND
On 19 Jun 2020, at 17:56, Ralph Campbell wrote:
> Transparent huge page allocation policy is controlled by several sysfs
> variables. Rather than expose these to each device driver that needs to
> allocate THPs, provide a helper function.
>
> Signed-off-by: Ralph Campbell
> ---
>
On 19 Jun 2020, at 17:56, Ralph Campbell wrote:
> Support transparent huge page migration to ZONE_DEVICE private memory.
> A new flag (MIGRATE_PFN_COMPOUND) is added to the input PFN array to
> indicate the huge page was fully mapped by the CPU.
> Export prep_compound_page() so that device
> Signed-off-by: Yang Shi
> ---
Makes sense to me.
Reviewed-by: Zi Yan
—
Best Regards,
Yan Zi
signature.asc
Description: OpenPGP digital signature
On 10 Jun 2020, at 16:12, Matthew Wilcox wrote:
> From: "Matthew Wilcox (Oracle)"
>
> Introduce the new page policy of PF_SECOND which lets us use the
> normal pageflags generation machinery to create the various DoubleMap
> manipulation functions.
>
> Signed-off-by: Matthew Wilcox (Oracle)
>
ar to have Private2 set. Use the
> Workingset bit instead which is defined as PF_HEAD so any attempt to
> access the Workingset bit on a tail page will redirect to the head page's
> Workingset bit.
>
> Signed-off-by: Matthew Wilcox (Oracle)
> ---
Make sense to me.
Reviewed-by:
On 9 Jun 2020, at 7:35, Anshuman Khandual wrote:
> On 06/05/2020 07:54 PM, Zi Yan wrote:
>> On 4 Jun 2020, at 23:35, Anshuman Khandual wrote:
>>
>>> On 06/04/2020 10:19 PM, Zi Yan wrote:
>>>> On 4 Jun 2020, at 12:36, Matthew Wilcox wrote:
>>>>
&g
On 4 Jun 2020, at 23:35, Anshuman Khandual wrote:
> On 06/04/2020 10:19 PM, Zi Yan wrote:
>> On 4 Jun 2020, at 12:36, Matthew Wilcox wrote:
>>
>>> On Thu, Jun 04, 2020 at 09:51:10AM -0400, Zi Yan wrote:
>>>> On 4 Jun 2020, at 7:34, Matthew Wilcox wrote:
>
On 4 Jun 2020, at 12:36, Matthew Wilcox wrote:
> On Thu, Jun 04, 2020 at 09:51:10AM -0400, Zi Yan wrote:
>> On 4 Jun 2020, at 7:34, Matthew Wilcox wrote:
>>> On Thu, Jun 04, 2020 at 09:30:45AM +0530, Anshuman Khandual wrote:
>>>> +Quantifying Migration
>>>&
On 4 Jun 2020, at 7:34, Matthew Wilcox wrote:
> On Thu, Jun 04, 2020 at 09:30:45AM +0530, Anshuman Khandual wrote:
>> Add the following new VM events which will help in validating THP migration
>> without split. Statistics reported through these new events will help in
>> performance debugging.
line function rather than a macro.
>
> Signed-off-by: Matthew Wilcox (Oracle)
> ---
> include/linux/huge_mm.h | 5 +--
> include/linux/mm.h | 96 -
> 2 files changed, 50 insertions(+), 51 deletions(-)
>
Glad to see this change. Thanks.
On 8 May 2020, at 16:06, Ralph Campbell wrote:
> On 5/8/20 12:51 PM, Christoph Hellwig wrote:
>> On Fri, May 08, 2020 at 12:20:07PM -0700, Ralph Campbell wrote:
>>> hmm_range_fault() returns an array of page frame numbers and flags for
>>> how the pages are mapped in the requested process' page
101 - 200 of 754 matches
Mail list logo
