search for: config_memory_hotplug

...GB of memory with a memory block size of 128MB on x86-64). Let's allow to selectively merge system ram resources by specifying a new flag for add_memory*(). Patch #5 contains a /proc/iomem example. Only tested with virtio-mem. v3 -> v4: - "mm/memory_hotplug: guard more declarations by CONFIG_MEMORY_HOTPLUG" -- Fix configs without CONFIG_MEMORY_HOTPLUG with the new mhp_t type -- Did a buch of cross-compiles with different configs, hope there isn't anything I missed. v2 -> v3: - "mm/memory_hotplug: prepare passing flags to add_memory() and friends" -- Use proper __bitwise type...

...GB of memory with a memory block size of 128MB on x86-64). Let's allow to selectively merge system ram resources by specifying a new flag for add_memory*(). Patch #5 contains a /proc/iomem example. Only tested with virtio-mem. v3 -> v4: - "mm/memory_hotplug: guard more declarations by CONFIG_MEMORY_HOTPLUG" -- Fix configs without CONFIG_MEMORY_HOTPLUG with the new mhp_t type -- Did a buch of cross-compiles with different configs, hope there isn't anything I missed. v2 -> v3: - "mm/memory_hotplug: prepare passing flags to add_memory() and friends" -- Use proper __bitwise type...

...make: *** [fs] Error 2 Line 716 of fs/btrfs/disk-io.c is: return migrate_page(mapping, newpage, page); This is related to the "Btrfs: add migrate page for metadata inode" patch (the first patch in the set of patches added to the next-rc branch). When I configure my kernel with CONFIG_MEMORY_HOTPLUG=n, this automatically unconfigures CONFIG_MIGRATION. In include/linux/migrate.h, when CONFIG_MIGRATION is not set, migrate_page is defined as NULL: /* Possible settings for the migrate_page() method in address_operations */ #define migrate_page NULL So in this case, migrate_page is defined as NU...

...linux/ioport.h >> @@ -251,6 +251,9 @@ extern void __release_region(struct resource *, resource_size_t, >> extern void release_mem_region_adjustable(struct resource *, resource_size_t, >> resource_size_t); >> #endif >> +#ifdef CONFIG_MEMORY_HOTPLUG >> +extern void merge_system_ram_resources(struct resource *res); >> +#endif >> >> /* Wrappers for managed devices */ >> struct device; >> diff --git a/kernel/resource.c b/kernel/resource.c >> index 1dcef5d53d76e..b4e0963edadd2 100644 >> --- a/kerne...

...ot option (on by default to not break things using this interface now). If it be useful for maintainers of mm/memory_hotplug.c and drivers/base/memory.c code then I could do that. Currently original arch/x86/Kconfig version is restored. > >+/* we are OK calling __meminit stuff here - we have CONFIG_MEMORY_HOTPLUG > >*/ > >+static int __ref xen_add_memory(int nid, u64 start, u64 size) > > Could this be __meminit too then? Good question. I looked throught the code and could not find any simple explanation why mm/memory_hotplug.c authors used __ref instead __meminit. Could you (mm/memory_hot...

This is the follow-up of "[PATCH RFCv1 0/5] mm/memory_hotplug: selective merging of memory resources" [1] Some add_memory*() users add memory in small, contiguous memory blocks. Examples include virtio-mem, hyper-v balloon, and the XEN balloon. This can quickly result in a lot of memory resources, whereby the actual resource boundaries are not of interest (e.g., it might be relevant

...ME "xen_memory" @@ -199,6 +197,196 @@ static inline unsigned long current_target(void) { return balloon_stats.target_pages; } + +static inline u64 is_memory_resource_reserved(void) +{ + return balloon_stats.hotplug_start_paddr; +} + +/* we are OK calling __meminit stuff here - we have CONFIG_MEMORY_HOTPLUG */ +static int __ref xen_add_memory(int nid, u64 start, u64 size) +{ + pg_data_t *pgdat = NULL; + int new_pgdat = 0, ret; + + lock_system_sleep(); + + if (!node_online(nid)) { + pgdat = hotadd_new_pgdat(nid, start); + ret = -ENOMEM; + if (!pgdat) + goto out; + new_pgdat = 1; + } + + /* call a...

Some add_memory*() users add memory in small, contiguous memory blocks. Examples include virtio-mem, hyper-v balloon, and the XEN balloon. This can quickly result in a lot of memory resources, whereby the actual resource boundaries are not of interest (e.g., it might be relevant for DIMMs, exposed via /proc/iomem to user space). We really want to merge added resources in this scenario where

...FIG_CONTIG_ALLOC */ void free_contig_range(unsigned long pfn, unsigned int nr_pages) @@ -8483,6 +8484,7 @@ void free_contig_range(unsigned long pfn, unsigned int nr_pages) } WARN(count != 0, "%d pages are still in use!\n", count); } +EXPORT_SYMBOL_GPL(free_contig_range); #ifdef CONFIG_MEMORY_HOTPLUG /* -- 2.21.0

Some add_memory*() users add memory in small, contiguous memory blocks. Examples include virtio-mem, hyper-v balloon, and the XEN balloon. This can quickly result in a lot of memory resources, whereby the actual resource boundaries are not of interest (e.g., it might be relevant for DIMMs, exposed via /proc/iomem to user space). We really want to merge added resources in this scenario where

Some add_memory*() users add memory in small, contiguous memory blocks. Examples include virtio-mem, hyper-v balloon, and the XEN balloon. This can quickly result in a lot of memory resources, whereby the actual resource boundaries are not of interest (e.g., it might be relevant for DIMMs, exposed via /proc/iomem to user space). We really want to merge added resources in this scenario where

Some add_memory*() users add memory in small, contiguous memory blocks. Examples include virtio-mem, hyper-v balloon, and the XEN balloon. This can quickly result in a lot of memory resources, whereby the actual resource boundaries are not of interest (e.g., it might be relevant for DIMMs, exposed via /proc/iomem to user space). We really want to merge added resources in this scenario where

...ntig_range(unsigned long pfn, unsigned int nr_pages) > @@ -8483,6 +8484,7 @@ void free_contig_range(unsigned long pfn, unsigned int nr_pages) > } > WARN(count != 0, "%d pages are still in use!\n", count); > } > +EXPORT_SYMBOL_GPL(free_contig_range); > > #ifdef CONFIG_MEMORY_HOTPLUG > /* > -- > 2.21.0 -- Michal Hocko SUSE Labs

Hi David, I love your patch! Yet something to improve: [auto build test ERROR on next-20200909] [cannot apply to mmotm/master hnaz-linux-mm/master xen-tip/linux-next powerpc/next linus/master v5.9-rc4 v5.9-rc3 v5.9-rc2 v5.9-rc4] [If your patch is applied to the wrong git tree, kindly drop us a note. And when submitting patch, we suggest to use '--base' as documented in

...e); diff --git a/mm/memory_hotplug.c b/mm/memory_hotplug.c index 8e1cd18b5cf14..64b07f006bc10 100644 --- a/mm/memory_hotplug.c +++ b/mm/memory_hotplug.c @@ -1039,7 +1039,8 @@ static int online_memory_block(struct memory_block *mem, void *arg) * * we are OK calling __meminit stuff here - we have CONFIG_MEMORY_HOTPLUG */ -int __ref add_memory_resource(int nid, struct resource *res) +int __ref add_memory_resource(int nid, struct resource *res, + unsigned long flags) { struct mhp_params params = { .pgprot = PAGE_KERNEL }; u64 start, size; @@ -1118,7 +1119,7 @@ int __ref add_memory_resource(int nid,...

...e); diff --git a/mm/memory_hotplug.c b/mm/memory_hotplug.c index 8e1cd18b5cf14..8f0bd7c9a63a5 100644 --- a/mm/memory_hotplug.c +++ b/mm/memory_hotplug.c @@ -1039,7 +1039,7 @@ static int online_memory_block(struct memory_block *mem, void *arg) * * we are OK calling __meminit stuff here - we have CONFIG_MEMORY_HOTPLUG */ -int __ref add_memory_resource(int nid, struct resource *res) +int __ref add_memory_resource(int nid, struct resource *res, mhp_t mhp_flags) { struct mhp_params params = { .pgprot = PAGE_KERNEL }; u64 start, size; @@ -1118,7 +1118,7 @@ int __ref add_memory_resource(int nid, struct resourc...

Hi all, I am using Xen 4.0.0 on top of Ubuntu Lucid (amd64), with the Jeremy kernel taken from git (xen/stable-2.6.32.x branch, 2.6.32.12 when I am writing this email). This kernel is also used in my domu. I can save a domu without any problem, but restoring it may need from 2 to 5 minutes, from a 1G checkpoint file (domu has 1GB RAM). There also errors in /var/log/xen/xend.log :

Hi all, I am using Xen 4.0.0 on top of Ubuntu Lucid (amd64), with the Jeremy kernel taken from git (xen/stable-2.6.32.x branch, 2.6.32.12 when I am writing this email). This kernel is also used in my domu. I can save a domu without any problem, but restoring it may need from 2 to 5 minutes, from a 1G checkpoint file (domu has 1GB RAM). There also errors in /var/log/xen/xend.log :

This is the follow up of [1]: [PATCH v1 0/3] mm/memory_hotplug: Make virtio-mem play nicely with kexec-tools I realized that this is not only helpful for virtio-mem, but also for dax/kmem - it's a fix for that use case (see patch #3) of persistent memory. Also, while testing, I discovered that kexec-tools will *not* add dax/kmem memory (anything not directly under the root when parsing

This series is based on [1]: [PATCH v2 00/10] virtio-mem: paravirtualized memory That will hopefull get picked up soon, rebased to -next. The following patches were reverted from -next [2]: [PATCH 0/3] kexec/memory_hotplug: Prevent removal and accidental use As discussed in that thread, they should be reverted from -next already. In theory, if people agree, we could take the first two patches