search for: zone_norm

...> > What does your .config specify for CONFIG_MEMORY_HOTPLUG_DEFAULT_ONLINE? > > I'll try to reproduce with v4 briefly. I guess I know what's happening here. In case we only have DMA memory when booting, we don't reserve swiotlb buffers. Once we hotplug memory and online ZONE_NORMAL, we don't have any swiotlb DMA bounce buffers to map such PFNs (total 0 (slots), used 0 (slots)). Can you try with "swiotlb=force" on the kernel cmdline? -- Thanks, David / dhildenb

...> > What does your .config specify for CONFIG_MEMORY_HOTPLUG_DEFAULT_ONLINE? > > I'll try to reproduce with v4 briefly. I guess I know what's happening here. In case we only have DMA memory when booting, we don't reserve swiotlb buffers. Once we hotplug memory and online ZONE_NORMAL, we don't have any swiotlb DMA bounce buffers to map such PFNs (total 0 (slots), used 0 (slots)). Can you try with "swiotlb=force" on the kernel cmdline? -- Thanks, David / dhildenb

? 2020/6/5 ??6:05, David Hildenbrand ??: >> I guess I know what's happening here. In case we only have DMA memory >> when booting, we don't reserve swiotlb buffers. Once we hotplug memory >> and online ZONE_NORMAL, we don't have any swiotlb DMA bounce buffers to >> map such PFNs (total 0 (slots), used 0 (slots)). >> >> Can you try with "swiotlb=force" on the kernel cmdline? > Alternative, looks like you can specify "-m 2G,maxmem=16G,slots=1", to > create prop...

? 2020/6/5 ??6:05, David Hildenbrand ??: >> I guess I know what's happening here. In case we only have DMA memory >> when booting, we don't reserve swiotlb buffers. Once we hotplug memory >> and online ZONE_NORMAL, we don't have any swiotlb DMA bounce buffers to >> map such PFNs (total 0 (slots), used 0 (slots)). >> >> Can you try with "swiotlb=force" on the kernel cmdline? > Alternative, looks like you can specify "-m 2G,maxmem=16G,slots=1", to > create prop...

At OLS we had a couple of "Xen Mini Summit" sessions. Although there weren''t any formal minutes, here''s a rough summary of what we discussed/concluded. Status as of 24 July 2005 ========================= Summary: We have a couple of annoying bugs, but things are coming together nicely. x86_32p (PAE 16GB) and x86_64 ports are close to being feature complete with

...() > only on ranges that belong to the same node/zone in at least > MAX(MAX_ORDER - 1, pageblock_order) order granularity - e.g., 4MB on > x86-64. The virtio-mem device added that memory, so the memory > exists and does not contain any holes. virtio-mem will only try to allocate > on ZONE_NORMAL, never on ZONE_MOVABLE, just like when allocating > gigantic pages (we don't put unmovable data into the movable zone). Same feedback as in pxm_to_node export. No objections to exporting the symbol but it would be better to squash this function into the patch which uses it. The changelog...

...one, the managed page count of both zones is wrong. Paired with memory offlining (which will adjust the managed page count), we can trigger kernel crashes and all kinds of different symptoms. One way to reproduce: 1. Start a QEMU guest with 4GB, no NUMA 2. Hotplug a 1GB DIMM and only the memory to ZONE_NORMAL 3. Inflate the balloon to 1GB 4. Unplug the DIMM (be quick, otherwise unmovable data ends up on it) 5. Observe /proc/zoneinfo Node 0, zone Normal pages free 16810 min 24848885473806 low 18471592959183339 high 36918337032892872 span...

...one, the managed page count of both zones is wrong. Paired with memory offlining (which will adjust the managed page count), we can trigger kernel crashes and all kinds of different symptoms. One way to reproduce: 1. Start a QEMU guest with 4GB, no NUMA 2. Hotplug a 1GB DIMM and only the memory to ZONE_NORMAL 3. Inflate the balloon to 1GB 4. Unplug the DIMM (be quick, otherwise unmovable data ends up on it) 5. Observe /proc/zoneinfo Node 0, zone Normal pages free 16810 min 24848885473806 low 18471592959183339 high 36918337032892872 span...

...() > only on ranges that belong to the same node/zone in at least > MAX(MAX_ORDER - 1, pageblock_order) order granularity - e.g., 4MB on > x86-64. The virtio-mem device added that memory, so the memory > exists and does not contain any holes. virtio-mem will only try to allocate > on ZONE_NORMAL, never on ZONE_MOVABLE, just like when allocating > gigantic pages (we don't put unmovable data into the movable zone). Is there any real reason to export as GPL rather than generic EXPORT_SYMBOL? In other words do we need to restrict the usage this interface only to GPL modules and why i...

...one, the managed page count of both zones is wrong. Paired with memory offlining (which will adjust the managed page count), we can trigger kernel crashes and all kinds of different symptoms. One way to reproduce: 1. Start a QEMU guest with 4GB, no NUMA 2. Hotplug a 1GB DIMM and only the memory to ZONE_NORMAL 3. Inflate the balloon to 1GB 4. Unplug the DIMM (be quick, otherwise unmovable data ends up on it) 5. Observe /proc/zoneinfo Node 0, zone Normal pages free 16810 min 24848885473806 low 18471592959183339 high 36918337032892872 span...

...one, the managed page count of both zones is wrong. Paired with memory offlining (which will adjust the managed page count), we can trigger kernel crashes and all kinds of different symptoms. One way to reproduce: 1. Start a QEMU guest with 4GB, no NUMA 2. Hotplug a 1GB DIMM and only the memory to ZONE_NORMAL 3. Inflate the balloon to 1GB 4. Unplug the DIMM (be quick, otherwise unmovable data ends up on it) 5. Observe /proc/zoneinfo Node 0, zone Normal pages free 16810 min 24848885473806 low 18471592959183339 high 36918337032892872 span...

...rtio-mem device. add_memory()/try_remove_memory() is used to add/remove memory blocks. virtio-mem will not online memory blocks itself. This has to be done by user space, or configured into the kernel (CONFIG_MEMORY_HOTPLUG_DEFAULT_ONLINE). virtio-mem will only unplug memory that was online to the ZONE_NORMAL. Memory is suggested to be onlined to the ZONE_NORMAL for now. The memory hotplug notifier is used to properly synchronize against onlining/offlining of memory blocks and to track the states of memory blocks (including the zone memory blocks are onlined to). Locking is done similar to the PPC CM...

...nge() / free_contig_range() only on ranges that belong to the same node/zone in at least MAX(MAX_ORDER - 1, pageblock_order) order granularity - e.g., 4MB on x86-64. The virtio-mem device added that memory, so the memory exists and does not contain any holes. virtio-mem will only try to allocate on ZONE_NORMAL, never on ZONE_MOVABLE, just like when allocating gigantic pages (we don't put unmovable data into the movable zone). Cc: Andrew Morton <akpm at linux-foundation.org> Cc: Michal Hocko <mhocko at suse.com> Cc: Vlastimil Babka <vbabka at suse.cz> Cc: Oscar Salvador <osalva...

....config specify for CONFIG_MEMORY_HOTPLUG_DEFAULT_ONLINE? >> >> I'll try to reproduce with v4 briefly. > > I guess I know what's happening here. In case we only have DMA memory > when booting, we don't reserve swiotlb buffers. Once we hotplug memory > and online ZONE_NORMAL, we don't have any swiotlb DMA bounce buffers to > map such PFNs (total 0 (slots), used 0 (slots)). > > Can you try with "swiotlb=force" on the kernel cmdline? Alternative, looks like you can specify "-m 2G,maxmem=16G,slots=1", to create proper ACPI tables that...

On 05.06.20 12:46, Alex Shi wrote: > > > ? 2020/6/5 ??6:05, David Hildenbrand ??: >>> I guess I know what's happening here. In case we only have DMA memory >>> when booting, we don't reserve swiotlb buffers. Once we hotplug memory >>> and online ZONE_NORMAL, we don't have any swiotlb DMA bounce buffers to >>> map such PFNs (total 0 (slots), used 0 (slots)). >>> >>> Can you try with "swiotlb=force" on the kernel cmdline? >> Alternative, looks like you can specify "-m 2G,maxmem=16G,slots=1", to...

...inux/mmzone.h >> index f6f884970511d..600d449e7d9e9 100644 >> --- a/include/linux/mmzone.h >> +++ b/include/linux/mmzone.h >> @@ -372,6 +372,40 @@ enum zone_type { >> */ >> ZONE_HIGHMEM, >> #endif >> + /* >> + * ZONE_MOVABLE is similar to ZONE_NORMAL, except that it *primarily* >> + * only contains movable pages. Main use cases are to make memory > > "Primarily only" sounds awkward. Maybe > > ... except that it only contains movable pages with few exceptional > cases described below. > > And then &...

...>>>> --- a/include/linux/mmzone.h >>>> +++ b/include/linux/mmzone.h >>>> @@ -372,6 +372,40 @@ enum zone_type { >>>> */ >>>> ZONE_HIGHMEM, >>>> #endif >>>> + /* >>>> + * ZONE_MOVABLE is similar to ZONE_NORMAL, except that it *primarily* >>>> + * only contains movable pages. Main use cases are to make memory >>> >>> "Primarily only" sounds awkward. Maybe >>> >>> ... except that it only contains movable pages with few exceptional >>>...

...nge() / free_contig_range() only on ranges that belong to the same node/zone in at least MAX(MAX_ORDER - 1, pageblock_order) order granularity - e.g., 4MB on x86-64. The virtio-mem device added that memory, so the memory exists and does not contain any holes. virtio-mem will only try to allocate on ZONE_NORMAL, never on ZONE_MOVABLE, just like when allocating gigantic pages (we don't put unmovable data into the movable zone). Cc: Andrew Morton <akpm at linux-foundation.org> Cc: Michal Hocko <mhocko at suse.com> Cc: Vlastimil Babka <vbabka at suse.cz> Cc: Oscar Salvador <osalva...

@Andrew can we give this a churn and consider it for v5.9 in case there are no more comments? Patch #1-#4 have RB's, patch #5 is virtio-mem stuff maintained by me, patch #6 is just a doc update. --- Currently, virtio-mem does not really support ZONE_MOVABLE. While it allows to online fully plugged memory blocks to ZONE_MOVABLE, it does not allow to online partially-plugged memory blocks to

@Andrew can we give this a churn and consider it for v5.9 in case there are no more comments? Patch #1-#4 have RB's, patch #5 is virtio-mem stuff maintained by me, patch #6 is just a doc update. --- Currently, virtio-mem does not really support ZONE_MOVABLE. While it allows to online fully plugged memory blocks to ZONE_MOVABLE, it does not allow to online partially-plugged memory blocks to