search for: zone_normal

...> > 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 proper...

? 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 proper...

...fy some things. Fuad, feel free to add additional information. > Honestly, I question this thesis. How complex would it be to have 'yet > more callbacks'? Is the challenge really that the mm can't detect when > guestmemfd is the owner of the page because the page will be > ZONE_NORMAL? Fuad might have been a bit imprecise here: We don't want an ever growing list of checks+callbacks on the page freeing fast path. This series replaces the two cases we have by a single generic one, which is nice independent of guest_memfd I think. > > So the point of this is really...

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

...r letter when I respin. Cheers, /fuad > > > Honestly, I question this thesis. How complex would it be to have 'yet > > more callbacks'? Is the challenge really that the mm can't detect when > > guestmemfd is the owner of the page because the page will be > > ZONE_NORMAL? > > Fuad might have been a bit imprecise here: We don't want an ever growing > list of checks+callbacks on the page freeing fast path. > > This series replaces the two cases we have by a single generic one, > which is nice independent of guest_memfd I think. > > > &g...

...() > 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 is...

...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 spanne...

...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 spanne...

...() > 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 if...

...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 spanne...

...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 spanne...

...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 CMA...

...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 <osalvado...

....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 in...

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 &g...

...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 &gt...

...>>>> --- 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 >>> ca...

...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 <osalvado...