.org/oe-lkp/202405281431.c46a3be9-...@intel.com
> Signed-off-by: David Hildenbrand
Reviewed-by: Oscar Salvador
Thanks!
--
Oscar Salvador
SUSE Labs
f 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
the page table.
>
> 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 holdin
sh, 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
altmap 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
with 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
allocations 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
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
3
.
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/hugetlb.c
off-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
: 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 flag from prep_new_hug
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
of 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
-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_hotplug.c
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_present_page_count()
Osca
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
the 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
ions(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
of 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
-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_hotplug.c
the 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
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
ne}_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: Introduce memor
urn 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
with 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
allocations 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
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
3
.
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/hugetlb.c
off-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
ed
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,block} return
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
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
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(+), 3 deletions(-)
d
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
with 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
.
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..6f39ec79face
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.
off-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
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,hugetlb: Drop clearin
he 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
> *
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,
> >
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
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 list th
odes 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
d you please elaborate some more?
Unless I am missing something, behaviour should not be any different with this
patch.
Thanks
--
Oscar Salvador
SUSE L3
_unlock(_lock);
>
> Should be be spin_unlock_irq(_lock);
>
> Other than that, it looks good.
Yeah, I will amend it in the next version.
Thanks Mike!
--
Oscar Salvador
SUSE L3
rtainly add it if you feel strong about it.
--
Oscar Salvador
SUSE L3
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 --git a/include/linux/hugetl
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
with 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
.
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/hugetlb.c
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
off-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
mportantly, 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_contig_migrate_rang
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
gt; 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
> Reviewed-by: Miaohe Lin
t does
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 th
n that tells us whether
we have any means to age those pages, a better fit would be something like
anon_can_be_aged(). IIUC, the "should age" part would be inactive_is_low().
--
Oscar Salvador
SUSE L3
On Thu, Apr 08, 2021 at 02:51:20PM -0700, Dave Hansen wrote:
> I've fleshed out the description a bit. I hope this helps?
Yes, thanks Dave, both additions look fine to me.
--
Oscar Salvador
SUSE L3
On Thu, Apr 08, 2021 at 10:05:18PM -0700, Andrew Morton wrote:
> Yes please.
I just sent v7 with that yesterday [1]
Hope David/Michal finds some time to review patch#4 as that is the only
missing piece atm.
[1] https://lkml.org/lkml/2021/4/8/546
--
Oscar Salvador
SUSE L3
ral times, as instead of a delta value, nr_succeeded
would accumulate.
But that won't happen neither with Wei Xu's version nor with mine.
--
Oscar Salvador
SUSE L3
On Thu, Apr 08, 2021 at 08:17:26PM +0200, Oscar Salvador wrote:
> diff --git a/include/linux/migrate.h b/include/linux/migrate.h
> index 3a389633b68f..fd661cb2ce13 100644
> --- a/include/linux/migrate.h
> +++ b/include/linux/migrate.h
> @@ -40,7 +40,8 @@ extern int migr
NTIG_RANGE);
+ NULL, (unsigned long), cc->mode,
MR_CONTIG_RANGE,
+ NULL);
}
if (ret < 0) {
putback_movable_pages(>migratepages);
As I said I might be missing a point here, but I cannot see the problem
you describe here.
--
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 5656e7aacd69..0e23acd173f0 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
-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
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
of free_pagetable.
Signed-off-by: Oscar Salvador
---
drivers/base/memory.c | 64 ++--
include/linux/memory.h | 8 +-
include/linux/memory_hotplug.h | 13
include/linux/memremap.h | 2 +-
include/linux/mmzone.h | 7 +-
mm/Kconfig | 5
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
-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_hotplug.c
the 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
ctions take care of initializing/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 in
n practice.
>
> Note: This just adds the start of infratructure for migration. It is
> actually disabled next to the FIXME in migrate_demote_page_ok().
>
> Signed-off-by: Dave Hansen
> Cc: Wei Xu
> Cc: Yang Shi
> Cc: David Rientjes
> Cc: Huang Ying
> Cc: Dan Williams
> Cc: osalvador
Reviewed-by: Oscar Salvador
--
Oscar Salvador
SUSE L3
succedded = nr_succedded;
+
return rc;
}
And pass only a valid pointer from demote_page_list() and NULL from all
the others?
I was just wondered after all those "unsigned int nr_succedded" in all
other functions.
This would also solve the "be careful to initialize nr_succedded"
problem?
--
Oscar Salvador
SUSE L3
ots* of CPUs.
I am not sure whether we have a mechanism to delay that until all CPUs
that are meant to be online are online? (after boot?)
That's probably happening in wonderland, but was just speaking out loud.
(Of course the same happen with memory_hotplug acpi operations.
All it takes is some qemu-handling)
--
Oscar Salvador
SUSE L3
1 - 100 of 1240 matches
Mail list logo
