>
> At some point, we should likely unify the two pte handling paths,
> similar to how we did it for pmds/puds.
>
> Signed-off-by: David Hildenbrand
Reviewed-by: Oscar Salvador
Should we scream if someone passes us a non-present entry?
> ---
> mm/huge_memory.c |
On Tue, Jun 17, 2025 at 05:43:35PM +0200, David Hildenbrand wrote:
> Let's clean it all further up.
>
> Signed-off-by: David Hildenbrand
Reviewed-by: Oscar Salvador
I was thinking maybe we want to pass 'struct vm_fault' directly to insert_pmd(),
and retrieve the fields
On Tue, Jun 17, 2025 at 05:43:36PM +0200, David Hildenbrand wrote:
> Let's clean it all further up.
>
> Signed-off-by: David Hildenbrand
Reviewed-by: Oscar Salvador
--
Oscar Salvador
SUSE Labs
On Tue, Jun 17, 2025 at 05:43:33PM +0200, David Hildenbrand wrote:
> Now unused, so let's drop it.
>
> Signed-off-by: David Hildenbrand
Reviewed-by: Oscar Salvador
--
Oscar Salvador
SUSE Labs
ble-check to enable such checks dynamically on-demand. Something
> for the future.
>
> Signed-off-by: David Hildenbrand
I'm confused, I'm missing something here.
Before this change we would return NULL if e.g: pfn > highest_memmap_pfn, but
now we just print the warning and call pfn_to_page() anyway.
AFAIK, pfn_to_page() doesn't return NULL?
--
Oscar Salvador
SUSE Labs
;
> Add folio_mk_pud() to mimic what we do with folio_mk_pmd().
>
> Fixes: dbe54153296d ("mm/huge_memory: add vmf_insert_folio_pud()")
> Reviewed-by: Dan Williams
> Reviewed-by: Lorenzo Stoakes
> Reviewed-by: Jason Gunthorpe
> Tested-by: Dan Williams
> Signed-off-by: David Hildenbrand
Reviewed-by: Oscar Salvador
--
Oscar Salvador
SUSE Labs
On Fri, Jun 13, 2025 at 03:49:46PM +0200, Oscar Salvador wrote:
> Reviewed-by: Oscar salvador
Fat-fingers on a Friday afternoon:
Reviewed-by: Oscar Salvador
--
Oscar Salvador
SUSE Labs
ving a little comment in insert_pmd() noting why pmds mapping normal
folios cannot be marked special would be nice.
But just saying :-)
Reviewed-by: Oscar salvador
--
Oscar Salvador
SUSE Labs
by code inspection.
>
> Fixes: 7b806d229ef1 ("mm: remove vmf_insert_pfn_xxx_prot() for huge
> page-table entries")
> Reviewed-by: Dan Williams
> Reviewed-by: Lorenzo Stoakes
> Reviewed-by: Jason Gunthorpe
> Tested-by: Dan Williams
> Cc:
> Signed-off-by: David Hildenbrand
Reviewed-by: Oscar Salvador
--
Oscar Salvador
SUSE Labs
o_mk_pmd().
>
> While at it, make sure that the pud that is non-none is actually present
> before comparing PFNs.
>
> Fixes: dbe54153296d ("mm/huge_memory: add vmf_insert_folio_pud()")
> Signed-off-by: David Hildenbrand
Reviewed-by: Oscar Salvador
--
Oscar Salvador
SUSE Labs
ke sure that a pmd that is not-none is actually present
> before comparing PFNs.
>
> Fixes: 6c88f72691f8 ("mm/huge_memory: add vmf_insert_folio_pmd()")
> Signed-off-by: David Hildenbrand
Reviewed-by: Oscar Salvador
--
Oscar Salvador
SUSE Labs
On Fri, Jun 06, 2025 at 10:23:11AM +0200, David Hildenbrand wrote:
> See my reply to Dan.
>
> Yet another boolean, yuck. Passing the folio and the pfn, yuck.
>
> (I have a strong opinion here ;) )
ok, I see it was already considered. No more questions then ;-)
--
Oscar Salvador
SUSE Labs
update_mmu_cache_pmd(vma, addr, pmd);
> + } else {
> + WARN_ON_ONCE(!is_huge_zero_pmd(*pmd));
> + }
So, this is pretty much insert_pfn_pmd without pmd_mkdevmap/pmd_mkspecial().
I guess vmf_inser_folio_pmd() doesn't have to be concerned with devmaps
either, right?
Looks good to me, just a nit: would it not be better to pass a boolean
to insert_pfn_pmd() that lets it know whether it "can" create a
devmap/special entries?
--
Oscar Salvador
SUSE Labs
_range_debug() internal to mm.
>
> Note that ptdump uses the precise same function for kernel walking as a
> convenience, so we permit this but make it very explicit by having
> walk_page_range_novma() invoke walk_kernel_page_table_range() in this case.
>
> Signed-off-by: Lorenz
where
the only user of it lives?
--
Oscar Salvador
SUSE Labs
t; should ever be referencing such pages.
>
> An alternative might be to have another callback chain from memory hotplug
> code, where a driver that owns that page could agree to skip the
> PageOffline() page. However, we would have to repeatedly issue these
> callbacks for individual PageOffline() pages, which does not sound
> compelling. As we have spare bits, let's use this simpler approach for
> now.
>
> Acked-by: Zi Yan
> Signed-off-by: David Hildenbrand
Acked-by: Oscar Salvador
--
Oscar Salvador
SUSE Labs
t; That logic resides in virtio_mem_online_page_cb().
Sorry, I had to re-cache this.
Ok, I think that now I caught up with the code.
I see that we mark it Offline in memmap_init_range(), and then
__free_pages_core() will clear the flag before releasing them to the
buddy.
Ok, I think it is much clear now, thanks for helping me out with the
details!
--
Oscar Salvador
SUSE Labs
e are unmovable PageOffline pages, which cannot be
migrated?
- So for a PageOffline to be able to be migrated away must be Movable or
marked PageOfflineSkipabble, making do_migrate_range ignore it
- PageOfflineSkipabble will be marked PageOffline upon re-onlining? Will
still be marked as PageOfflineSkipabble?
> +
> +
> Closes: https://lore.kernel.org/oe-lkp/202405281431.c46a3be9-...@intel.com
> Signed-off-by: David Hildenbrand
Reviewed-by: Oscar Salvador
Thanks!
--
Oscar Salvador
SUSE Labs
ome
of that.
Maybe David remembers better, but I think we could remove that
__ClearPageReserved.
Looking at powerpc implementation code, it does not do the
__ClearPageReserved and relies only on free_reserved_page().
I will have a look.
--
Oscar Salvador
SUSE Labs
always easier to do it now that when the code goes already in,
so please consider if you really need SPARSEMEM and why (I do not think
you do).
--
Oscar Salvador
SUSE Labs
able.
>
> This change is analogous to arm64's commit bf2b59f60ee1 ("arm64/mm:
> Hold memory hotplug lock while walking for kernel page table dump").
>
> Signed-off-by: Björn Töpel
Reviewed-by: Oscar Salvador
funny enough, it seems arm64 and riscv are the only ones h
please consider to tight the
hotplug dependency to CONFIG_SPARSEMEM_VMEMMAP.
As a bonus, you will only have to maintain one flavour of functions.
--
Oscar Salvador
SUSE Labs
On Tue, May 14, 2024 at 04:04:41PM +0200, Björn Töpel wrote:
> From: Björn Töpel
>
> Add a parameter to the direct map setup function, so it can be used in
> arch_add_memory() later.
>
> Signed-off-by: Björn Töpel
Reviewed-by: Oscar Salvador
> ---
> a
p parameter is properly passed on to
> vmemmap_populate_hugepages().
>
> Signed-off-by: Björn Töpel
Reviewed-by: Oscar Salvador
> +static void __meminit create_linear_mapping_range(phys_addr_t start,
> phys_addr_t end,
> + uintptr_t fixed_map_s
when using hugetlb-vmemmap
optimization.
Users can always check whether the feature is enabled via
/sys/modules/memory_hotplug/parameters/memmap_on_memory.
Also, I did not check if it is, but if not, the fact about hugetlb-vmemmmap vs
hotplug-vmemmap should also be called out in the hugetlb-vmemmap kernel
parameter.
Thanks
--
Oscar Salvador
SUSE L3
hugetlb pages.
Either way, those checks are racy so let the end function handle it
when the time comes.
Signed-off-by: Oscar Salvador
Suggested-by: David Hildenbrand
Reviewed-by: David Hildenbrand
Acked-by: Mike Kravetz
Acked-by: Michal Hocko
---
mm/page_alloc.c | 6 --
1 file changed, 6
ations do not get this initialization
(see prep_compound_page).
Signed-off-by: Oscar Salvador
Acked-by: Michal Hocko
Reviewed-by: David Hildenbrand
Reviewed-by: Mike Kravetz
---
mm/hugetlb.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/mm/hugetlb.c b/mm/hugetlb.c
index 54d81d5947ed..2cb9fa79cbaa 100
them, and have much better chances to succeed the call.
Signed-off-by: Oscar Salvador
Reviewed-by: Mike Kravetz
Acked-by: Michal Hocko
Acked-by: David Hildenbrand
---
include/linux/hugetlb.h | 5 +++--
mm/compaction.c | 12 +++-
mm/hugetlb.c| 22
yclic
dependency between them and alloc_contig_range.
Signed-off-by: Oscar Salvador
Acked-by: Michal Hocko
Acked-by: David Hildenbrand
Reviewed-by: Mike Kravetz
---
include/linux/hugetlb.h | 6 +++
mm/compaction.c | 33 --
mm/hugetlb.c| 116
next patch.
prep_new_huge_page() still calls both functions.
Signed-off-by: Oscar Salvador
Acked-by: Michal Hocko
Reviewed-by: Mike Kravetz
Reviewed-by: David Hildenbrand
---
mm/hugetlb.c | 20 +---
1 file changed, 17 insertions(+), 3 deletions(-)
diff --git a/mm/hugetlb.c b/mm
-by: Oscar Salvador
Acked-by: Vlastimil Babka
Acked-by: Mike Kravetz
Reviewed-by: David Hildenbrand
---
mm/compaction.c | 52 +---
mm/internal.h | 10 --
mm/page_alloc.c | 7 +++
3 files changed, 36 insertions(+), 33 deletions(-)
d
away on -ENOMEM because it is considered a fatal
error. Do the same here instead of keep going and retrying.
Note that this is not fixing a real issue, just a cosmetic change. Although we
can save some cycles by backing off ealier
Signed-off-by: Oscar Salvador
Acked-by: Vlastimil Babka
Reviewed-by
048
HugePages_Free: 2048
HugePages_Rsvd:0
HugePages_Surp:0"
Oscar Salvador (7):
mm,page_alloc: Bail out earlier on -ENOMEM in
alloc_contig_migrate_range
mm,compaction: Let isolate_migratepages_{range,block} return error
codes
mm,hugetlb: Drop clearing of fl
On Fri, Apr 16, 2021 at 05:49:20PM +0800, Baoquan He wrote:
> On 04/16/21 at 09:00am, Oscar Salvador wrote:
> ...
> > +/*
> > + * alloc_and_dissolve_huge_page - Allocate a new page and dissolve the old
> > one
> > + * @h: struct hstate old page belongs to
> >
Enable arm64 platform to use the MHP_MEMMAP_ON_MEMORY feature.
Signed-off-by: Oscar Salvador
Reviewed-by: David Hildenbrand
---
arch/arm64/Kconfig | 3 +++
1 file changed, 3 insertions(+)
diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
index e4e1b6550115..68735831b236 100644
--- a/arch
Enable x86_64 platform to use the MHP_MEMMAP_ON_MEMORY feature.
Signed-off-by: Oscar Salvador
Reviewed-by: David Hildenbrand
---
arch/x86/Kconfig | 3 +++
1 file changed, 3 insertions(+)
diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index 2792879d398e..9f0211df1746 100644
--- a/arch/x86
memory_hotplug.memmap_on_memory parameter.
Signed-off-by: Oscar Salvador
Reviewed-by: David Hildenbrand
Acked-by: Michal Hocko
---
Documentation/admin-guide/kernel-parameters.txt | 17 +
mm/Makefile | 5 -
mm/memory_hotplug.c
-by: Oscar Salvador
Reviewed-by: David Hildenbrand
Acked-by: Michal Hocko
---
drivers/acpi/acpi_memhotplug.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/acpi/acpi_memhotplug.c b/drivers/acpi/acpi_memhotplug.c
index b02fd51e5589..8cc195c4c861 100644
--- a
free_pagetable.
Signed-off-by: Oscar Salvador
Reviewed-by: David Hildenbrand
---
drivers/base/memory.c | 71 --
include/linux/memory.h | 8 ++-
include/linux/memory_hotplug.h | 15 +++-
include/linux/memremap.h | 2 +-
include/linux/mmzone.h | 7
ff-by: Oscar Salvador
Reviewed-by: Oscar Salvador
---
mm/memory_hotplug.c | 22 --
1 file changed, 12 insertions(+), 10 deletions(-)
diff --git a/mm/memory_hotplug.c b/mm/memory_hotplug.c
index 25e59d5dc13c..d05056b3c173 100644
--- a/mm/memory_hotplug.c
+++ b/mm/memory_hotp
lizing/unitializing vmemmap pages
prior to calling {online,offline}_pages, so the latter functions can
remain totally untouched.
More details can be found in the respective changelogs.
David Hildenbrand (1):
mm,memory_hotplug: Factor out adjusting present pages into
adjust_presen
When using self-hosted vmemmap pages, the number of pages passed to
{online,offline}_pages might not fully span sections, but they always
fully span pageblocks.
Relax the check account for that case.
Signed-off-by: Oscar Salvador
Reviewed-by: David Hildenbrand
---
mm/memory_hotplug.c | 18
initialization and proper accounting of such
pages.
Since memory_block struct contains all the information, pass this struct
down the chain till the end functions.
Signed-off-by: Oscar Salvador
Reviewed-by: David Hildenbrand
---
drivers/base/memory.c | 33 +
1 file changed
end_pfn)
{
@@ -644,7 +643,6 @@ void offline_mem_sections(unsigned long start_pfn, unsigned
long end_pfn)
ms->section_mem_map &= ~SECTION_IS_ONLINE;
}
}
-#endif
#ifdef CONFIG_SPARSEMEM_VMEMMAP
static struct page * __meminit populate_section_memmap(unsigned long pfn,
--
Oscar Salvador
SUSE L3
But looking at online_pages(), we do it after the
move_pfn_range_to_zone(), right? AFAIK (I might be well wrong here),
memory_notify() will eventually call kasan_add_zero_shadow? So that
comes after the move_pfn_range_to_zone? Or is my understanding
incorrect?
--
Oscar Salvador
SUSE L3
Enable arm64 platform to use the MHP_MEMMAP_ON_MEMORY feature.
Signed-off-by: Oscar Salvador
Reviewed-by: David Hildenbrand
---
arch/arm64/Kconfig | 3 +++
1 file changed, 3 insertions(+)
diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
index e4e1b6550115..68735831b236 100644
--- a/arch
Enable x86_64 platform to use the MHP_MEMMAP_ON_MEMORY feature.
Signed-off-by: Oscar Salvador
Reviewed-by: David Hildenbrand
---
arch/x86/Kconfig | 3 +++
1 file changed, 3 insertions(+)
diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index 2792879d398e..9f0211df1746 100644
--- a/arch/x86
memory_hotplug.memmap_on_memory parameter.
Signed-off-by: Oscar Salvador
Reviewed-by: David Hildenbrand
Acked-by: Michal Hocko
---
Documentation/admin-guide/kernel-parameters.txt | 17 +
mm/Makefile | 5 -
mm/memory_hotplug.c
-by: Oscar Salvador
Reviewed-by: David Hildenbrand
Acked-by: Michal Hocko
---
drivers/acpi/acpi_memhotplug.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/acpi/acpi_memhotplug.c b/drivers/acpi/acpi_memhotplug.c
index b02fd51e5589..8cc195c4c861 100644
--- a
free_pagetable.
Signed-off-by: Oscar Salvador
---
drivers/base/memory.c | 75 --
include/linux/memory.h | 8 +-
include/linux/memory_hotplug.h | 17 +++-
include/linux/memremap.h | 2 +-
include/linux/mmzone.h | 7 +-
mm/Kconfig
ff-by: Oscar Salvador
Reviewed-by: Oscar Salvador
---
mm/memory_hotplug.c | 22 --
1 file changed, 12 insertions(+), 10 deletions(-)
diff --git a/mm/memory_hotplug.c b/mm/memory_hotplug.c
index 25e59d5dc13c..d05056b3c173 100644
--- a/mm/memory_hotplug.c
+++ b/mm/memory_hotp
When using self-hosted vmemmap pages, the number of pages passed to
{online,offline}_pages might not fully span sections, but they always
fully span pageblocks.
Relax the check account for that case.
Signed-off-by: Oscar Salvador
Reviewed-by: David Hildenbrand
---
mm/memory_hotplug.c | 18
initialization and proper accounting of such
pages.
Since memory_block struct contains all the information, pass this struct
down the chain till the end functions.
Signed-off-by: Oscar Salvador
Reviewed-by: David Hildenbrand
---
drivers/base/memory.c | 33 +
1 file changed
g {online,offline}_pages, so the latter functions can
remain totally untouched.
More details can be found in the respective changelogs.
David Hildenbrand (1):
mm,memory_hotplug: Factor out adjusting present pages into
adjust_present_page_count()
Oscar Salvador (7):
drivers/base/memory:
eturn ret;
> }
>
> if (nr_vmemmap_pages)
> mhp_deinit_memmap_on_memory(start_pfn, nr_vmemmap_pages);
> return 0;
> }
>
> Having to do the present page adjustment manually is not completely nice,
> but it's easier than manually having to mess with zones becomming
> populated/unpopulated
> outside of online_pages()/offline_pages().
Ok, I like this, and the naming is much better.
I will work on this shortly.
thanks David!
--
Oscar Salvador
SUSE L3
hugetlb pages.
Either way, those checks are racy so let the end function handle it
when the time comes.
Signed-off-by: Oscar Salvador
Suggested-by: David Hildenbrand
Reviewed-by: David Hildenbrand
Acked-by: Mike Kravetz
Acked-by: Michal Hocko
---
mm/page_alloc.c | 6 --
1 file changed, 6
them, and have much better chances to succeed the call.
Signed-off-by: Oscar Salvador
Reviewed-by: Mike Kravetz
Acked-by: Michal Hocko
---
include/linux/hugetlb.h | 5 +++--
mm/compaction.c | 12 +++-
mm/hugetlb.c| 24 ++--
mm/vmscan.c
ations do not get this initialization
(see prep_compound_page).
Signed-off-by: Oscar Salvador
Acked-by: Michal Hocko
Reviewed-by: David Hildenbrand
Reviewed-by: Mike Kravetz
---
mm/hugetlb.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/mm/hugetlb.c b/mm/hugetlb.c
index 54d81d5947ed..2cb9fa79cbaa 100
yclic
dependency between them and alloc_contig_range.
Signed-off-by: Oscar Salvador
Acked-by: Michal Hocko
Acked-by: David Hildenbrand
Reviewed-by: Mike Kravetz
---
include/linux/hugetlb.h | 6 +++
mm/compaction.c | 33 --
mm/hugetlb.c| 116
next patch.
prep_new_huge_page() still calls both functions.
Signed-off-by: Oscar Salvador
Acked-by: Michal Hocko
Reviewed-by: Mike Kravetz
Reviewed-by: David Hildenbrand
---
mm/hugetlb.c | 20 +---
1 file changed, 17 insertions(+), 3 deletions(-)
diff --git a/mm/hugetlb.c b/mm
-by: Oscar Salvador
Acked-by: Vlastimil Babka
Acked-by: Mike Kravetz
Reviewed-by: David Hildenbrand
---
mm/compaction.c | 52 +---
mm/internal.h | 10 --
mm/page_alloc.c | 7 +++
3 files changed, 36 insertions(+), 33 deletions(-)
d
le, as configured
by the admin (me):
HugePages_Total:2048
HugePages_Free: 2048
HugePages_Rsvd:0
HugePages_Surp:0"
Oscar Salvador (7):
mm,page_alloc: Bail out earlier on -ENOMEM in
alloc_contig_migrate_range
mm,compaction: Let isolate_migratepages_{range
away on -ENOMEM because it is considered a fatal
error. Do the same here instead of keep going and retrying.
Note that this is not fixing a real issue, just a cosmetic change. Although we
can save some cycles by backing off ealier
Signed-off-by: Oscar Salvador
Acked-by: Vlastimil Babka
Reviewed-by
On Thu, Apr 08, 2021 at 02:17:56PM +0200, Oscar Salvador wrote:
> Hi,
>
> I decided to send another version with the fixups included as it seemed a bit
> awkward otherwise. It should ease the review.
> Sorry for the spam.
Gentle ping :-)
hint: patch#4 is the one that nee
yclic
dependency between them and alloc_contig_range.
Signed-off-by: Oscar Salvador
Acked-by: Michal Hocko
---
include/linux/hugetlb.h | 6 +++
mm/compaction.c | 35 +--
mm/hugetlb.c| 117
3 files changed, 155 insertions
them, and have much better chances to succeed the call.
Signed-off-by: Oscar Salvador
Reviewed-by: Mike Kravetz
Acked-by: Michal Hocko
---
include/linux/hugetlb.h | 5 +++--
mm/compaction.c | 12 +++-
mm/hugetlb.c| 24 ++--
mm/vmscan.c
hugetlb pages.
Either way, those checks are racy so let the end function handle it
when the time comes.
Signed-off-by: Oscar Salvador
Suggested-by: David Hildenbrand
Reviewed-by: David Hildenbrand
Acked-by: Mike Kravetz
---
mm/page_alloc.c | 6 --
1 file changed, 6 deletions(-)
diff --git a
next patch.
prep_new_huge_page() still calls both functions.
Signed-off-by: Oscar Salvador
Acked-by: Michal Hocko
Reviewed-by: Mike Kravetz
---
mm/hugetlb.c | 20 +---
1 file changed, 17 insertions(+), 3 deletions(-)
diff --git a/mm/hugetlb.c b/mm/hugetlb.c
index 2cb9fa79cbaa..6f
ground, let us remove the clearing of the flag from
prep_new_huge_page() as it is not needed.
Signed-off-by: Oscar Salvador
---
mm/hugetlb.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/mm/hugetlb.c b/mm/hugetlb.c
index 54d81d5947ed..2cb9fa79cbaa 100644
--- a/mm/hugetlb.c
+++ b/mm/hugetlb.
-by: Oscar Salvador
Acked-by: Vlastimil Babka
Acked-by: Mike Kravetz
---
mm/compaction.c | 52 +---
mm/internal.h | 10 --
mm/page_alloc.c | 7 +++
3 files changed, 36 insertions(+), 33 deletions(-)
diff --git a/mm/compaction.c b
away on -ENOMEM because it is considered a fatal
error. Do the same here instead of keep going and retrying.
Note that this is not fixing a real issue, just a cosmetic change. Although we
can save some cycles by backing off ealier
Signed-off-by: Oscar Salvador
Acked-by: Vlastimil Babka
Reviewed-by
ages_Total:2048
HugePages_Free: 2048
HugePages_Rsvd:0
HugePages_Surp:0"
Oscar Salvador (7):
mm,page_alloc: Bail out earlier on -ENOMEM in
alloc_contig_migrate_range
mm,compaction: Let isolate_migratepages_{range,block} return error
codes
mm,hugetl
act the whole zone, it goes through the zone).
alloc_contig_range() needs to isolate the whole range we specified in
order to be able to migrate it and make it free for whoever wants to use
it.
Let us say that the interface between alloc_contig_range() and
compaction still needs some more love that I plan to work on when this goes
in.
--
Oscar Salvador
SUSE L3
* prep_new_huge_page but that takes hugetlb_lock which
>* is already held so we need to open code it here.
>* Reference count trick is needed because allocator
>* gives us referenced page but the pool requires pages
>
ailing out right away without further retrying.
> > +*/
> > + if (hstate_is_gigantic(h))
> > + return -ENOMEM;
> > +
> > + return alloc_and_dissolve_huge_page(h, head);
> > +}
> > +
> > struct page *alloc_huge_page(struct vm_area_struct *vma,
> &g
f there are no objections, we can
get rid of the clearing flag right there.
--
Oscar Salvador
SUSE L3
On Wed, Apr 14, 2021 at 12:01:47PM +0200, Oscar Salvador wrote:
> but it seems that does not the memmap struct page.
that sould read as "but it seems that that does not affect the memmap struct
page"
--
Oscar Salvador
SUSE L3
fe to assume that we do not really need
to clear the flag in __prep_new_huge_page() routine?
--
Oscar Salvador
SUSE L3
On Wed, Apr 14, 2021 at 10:12:29AM +0200, David Hildenbrand wrote:
> My guest best is that fast class is something like HBM (High Bandwidth
> Memory), medium class is ordinary RAM, slow class is PMEM.
I see, thanks for the hint David ;-)
--
Oscar Salvador
SUSE L3
On Wed, Apr 14, 2021 at 10:08:54AM +0200, Oscar Salvador wrote:
> In Dave's example, list is created in a way that stays local to the socket,
> and we go from the fast one to the slow one.
Or maybe it is just because find_next_best_node() does not know any better
and creates the li
wer
nodes to give them a second chance, while your design seems more to have kind
of different memory clases and be able to place applications in one of those
tiers
depending on its demands or sysadmin-demand.
Could you expand some more?
--
Oscar Salvador
SUSE L3
ches page->private when coming from that
path.
--
Oscar Salvador
SUSE L3
be the case already because all
> the pages have been freed and there is no page to put on the PCP lists.
>
> Signed-off-by: Mel Gorman
Reviewed-by: Oscar Salvador
--
Oscar Salvador
SUSE L3
, could you please elaborate some more?
Unless I am missing something, behaviour should not be any different with this
patch.
Thanks
--
Oscar Salvador
SUSE L3
{
> > + spin_unlock(&hugetlb_lock);
>
> Should be be spin_unlock_irq(&hugetlb_lock);
>
> Other than that, it looks good.
Yeah, I will amend it in the next version.
Thanks Mike!
--
Oscar Salvador
SUSE L3
buys us much.
But I can certainly add it if you feel strong about it.
--
Oscar Salvador
SUSE L3
yclic
dependency between them and alloc_contig_range.
Signed-off-by: Oscar Salvador
---
include/linux/hugetlb.h | 6 +++
mm/compaction.c | 37 ++--
mm/hugetlb.c| 115
3 files changed, 155 insertions(+), 3 deletions(-)
diff
them, and have much better chances to succeed the call.
Signed-off-by: Oscar Salvador
Reviewed-by: Mike Kravetz
Acked-by: Michal Hocko
---
include/linux/hugetlb.h | 5 +++--
mm/compaction.c | 12 +++-
mm/hugetlb.c| 22 +-
mm/vmscan.c
hugetlb pages.
Either way, those checks are racy so let the end function handle it
when the time comes.
Signed-off-by: Oscar Salvador
Suggested-by: David Hildenbrand
Reviewed-by: David Hildenbrand
---
mm/page_alloc.c | 6 --
1 file changed, 6 deletions(-)
diff --git a/mm/page_alloc.c b/mm
next patch.
prep_new_huge_page() still calls both functions.
Signed-off-by: Oscar Salvador
---
mm/hugetlb.c | 19 ---
1 file changed, 16 insertions(+), 3 deletions(-)
diff --git a/mm/hugetlb.c b/mm/hugetlb.c
index e40d5fe5c63c..0607b2b71ac6 100644
--- a/mm/hugetlb.c
+++ b/mm
Currently, the clearing of the flag is done under the lock, but this
is unnecessary as we just allocated the page and we did not give it
away yet, so no one should be messing with it.
Also, this helps making clear that here the lock is only protecting the
counter.
Signed-off-by: Oscar Salvador
-by: Oscar Salvador
Acked-by: Vlastimil Babka
---
mm/compaction.c | 54 +++---
mm/internal.h | 10 --
mm/page_alloc.c | 7 +++
3 files changed, 38 insertions(+), 33 deletions(-)
diff --git a/mm/compaction.c b/mm/compaction.c
in
away on -ENOMEM because it is considered a fatal
error. Do the same here instead of keep going and retrying.
Note that this is not fixing a real issue, just a cosmetic change. Although we
can save some cycles by backing off ealier
Signed-off-by: Oscar Salvador
Acked-by: Vlastimil Babka
Reviewed-by
.
But more importantly, the hugepage count remains stable, as configured
by the admin (me):
HugePages_Total:2048
HugePages_Free: 2048
HugePages_Rsvd:0
HugePages_Surp:0"
Oscar Salvador (7):
mm,page_alloc: Bail out earlier on -ENOMEM in
alloc_cont
select ARCH_ENABLE_HUGEPAGE_MIGRATION if x86_64 && HUGETLB_PAGE &&
> MIGRATION
> select ARCH_ENABLE_MEMORY_HOTPLUG if X86_64 || (X86_32 && HIGHMEM)
> select ARCH_ENABLE_MEMORY_HOTREMOVE if MEMORY_HOTPLUG
> + select ARCH_ENABLE_THP_MIGRATION if x86_64 && TRANSPARENT_HUGEPAGE
you need s/x86_64/X86_64/, otherwise we are left with no migration :-)
--
Oscar Salvador
SUSE L3
held.
>
> Creating this routine and separating functionality is in preparation for
> restructuring code to reduce lock hold times. This commit should not
> introduce any changes to functionality.
>
> Signed-off-by: Mike Kravetz
> Acked-by: Michal Hocko
> Revie
es
not have to be hotplugged, but come functional by default (as RAM).
But after having read all papers out there, I do not think that it is possible.
--
Oscar Salvador
SUSE L3
On Fri, Apr 09, 2021 at 12:14:04PM +0200, Oscar Salvador wrote:
> On Thu, Apr 08, 2021 at 11:52:51AM +0200, Oscar Salvador wrote:
> > I am not really into PMEM, and I ignore whether we need
> > CONFIG_MEMORY_HOTPLUG in order to have such memory on the system.
> > If so, the fo
On Thu, Apr 08, 2021 at 11:52:51AM +0200, Oscar Salvador wrote:
> I am not really into PMEM, and I ignore whether we need
> CONFIG_MEMORY_HOTPLUG in order to have such memory on the system.
> If so, the following can be partly ignored.
Ok, I refreshed by memory with [1].
>From that, i
1 - 100 of 1019 matches
Mail list logo
