search for: zone_mov

@Andrew can we give this a churn and consider it for v5.9 in case there are no more comments? Patch #1-#4,#6 have RBss or ACKs, patch #5 is virtio-mem stuff maintained by me (and MST is aware). --- When introducing virtio-mem, the semantics of ZONE_MOVABLE were rather unclear, which is why we special-cased ZONE_MOVABLE such that partially plugged blocks would never end up in ZONE_MOVABLE. Now that the semantics are much clearer (and are documented in patch #6), let's support partially plugged memory blocks in ZONE_MOVABLE, allowing partially...

@Andrew can we give this a churn and consider it for v5.9 in case there are no more comments? Patch #1-#4,#6 have RBss or ACKs, patch #5 is virtio-mem stuff maintained by me (and MST is aware). --- When introducing virtio-mem, the semantics of ZONE_MOVABLE were rather unclear, which is why we special-cased ZONE_MOVABLE such that partially plugged blocks would never end up in ZONE_MOVABLE. Now that the semantics are much clearer (and are documented in patch #6), let's support partially plugged memory blocks in ZONE_MOVABLE, allowing partially...

...ider it for v5.9 in case there > are no more comments? @Andrew, Ping, so I assume we'll target v5.10? > > Patch #1-#4,#6 have RBss or ACKs, patch #5 is virtio-mem stuff maintained > by me (and MST is aware). > > --- > > When introducing virtio-mem, the semantics of ZONE_MOVABLE were rather > unclear, which is why we special-cased ZONE_MOVABLE such that partially > plugged blocks would never end up in ZONE_MOVABLE. > > Now that the semantics are much clearer (and are documented in patch #6), > let's support partially plugged memory blocks in ZONE_MO...

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 ZONE_MOVABLE and will never consider such memory blocks when unplugging memory. This might be surprising for users (especially, if onlining suddenly fails). Le...

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 ZONE_MOVABLE and will never consider such memory blocks when unplugging memory. This might be surprising for users (especially, if onlining suddenly fails). Le...

For 5.10. Patch #1-#4,#6 have RBs or ACKs, patch #5 is virtio-mem stuff maintained by me. This should go via the -mm tree. --- When introducing virtio-mem, the semantics of ZONE_MOVABLE were rather unclear, which is why we special-cased ZONE_MOVABLE such that partially plugged blocks would never end up in ZONE_MOVABLE. Now that the semantics are much clearer (and are documented in patch #6), let's support partially plugged memory blocks in ZONE_MOVABLE, allowing partially...

For 5.10. Patch #1-#4,#6 have RBs or ACKs, patch #5 is virtio-mem stuff maintained by me. This should go via the -mm tree. --- When introducing virtio-mem, the semantics of ZONE_MOVABLE were rather unclear, which is why we special-cased ZONE_MOVABLE such that partially plugged blocks would never end up in ZONE_MOVABLE. Now that the semantics are much clearer (and are documented in patch #6), let's support partially plugged memory blocks in ZONE_MOVABLE, allowing partially...

We can already have pages that can be offlined but not allocated in ZONE_MOVABLE - PageHWPoison pages. While these pages can be skipped when offlining ("moving them to /dev/null"), we cannot move them when allocating. virtio-mem managed memory is similar. The logical memory holes corresponding to unplug memory ranges can be skipped when offlining, however, the pa...

@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 ZONE_MOVABLE and will never consider such memory blocks when unplugging memory. This might be surprising for users (especially, if onlining suddenly fails). Le...

@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 ZONE_MOVABLE and will never consider such memory blocks when unplugging memory. This might be surprising for users (especially, if onlining suddenly fails). Le...

@Andrew, @Mst, I suggest the whole series (including the virtio-mem change) goes via the -mm tree. 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 ZONE_MOVABLE and will never consider such memory blocks when unplugging memory. This might be surprising for users (especially, if onlining suddenly fails). Le...

On 04.08.20 11:33, Mike Rapoport wrote: > On Tue, Aug 04, 2020 at 09:24:08AM +0200, David Hildenbrand wrote: >> Let's document what ZONE_MOVABLE means, how it's used, and which special >> cases we have regarding unmovable pages (memory offlining vs. migration / >> allocations). >> >> Cc: Andrew Morton <akpm at linux-foundation.org> >> Cc: Michal Hocko <mhocko at suse.com> >> Cc: Michae...

On 04.08.20 12:03, Mike Rapoport wrote: > On Tue, Aug 04, 2020 at 11:55:10AM +0200, David Hildenbrand wrote: >> On 04.08.20 11:33, Mike Rapoport wrote: >>> On Tue, Aug 04, 2020 at 09:24:08AM +0200, David Hildenbrand wrote: >>>> Let's document what ZONE_MOVABLE means, how it's used, and which special >>>> cases we have regarding unmovable pages (memory offlining vs. migration / >>>> allocations). >>>> >>>> Cc: Andrew Morton <akpm at linux-foundation.org> >>>> Cc: Michal Hocko <mh...

On Mon, 10 Aug 2020 09:56:32 +0200 David Hildenbrand <david at redhat.com> wrote: > On 04.08.20 21:41, David Hildenbrand wrote: > > @Andrew can we give this a churn and consider it for v5.9 in case there > > are no more comments? > > @Andrew, Ping, so I assume we'll target v5.10? Yep, sorry. Merging a significant patch series during the merge window(!) would be

On 16.08.20 14:53, David Hildenbrand wrote: > For 5.10. Patch #1-#4,#6 have RBs or ACKs, patch #5 is virtio-mem stuff > maintained by me. This should go via the -mm tree. > @Andrew, can we give this a churn if there are no further comments? Thanks! -- Thanks, David / dhildenb

On 21.08.20 10:46, Baoquan He wrote: > On 08/21/20 at 10:31am, David Hildenbrand wrote: >> On 16.08.20 14:53, David Hildenbrand wrote: >>> For 5.10. Patch #1-#4,#6 have RBs or ACKs, patch #5 is virtio-mem stuff >>> maintained by me. This should go via the -mm tree. >>> >> >> @Andrew, can we give this a churn if there are no further comments? Thanks!

On 21.08.20 10:31, David Hildenbrand wrote: > On 16.08.20 14:53, David Hildenbrand wrote: >> For 5.10. Patch #1-#4,#6 have RBs or ACKs, patch #5 is virtio-mem stuff >> maintained by me. This should go via the -mm tree. >> > > @Andrew, can we give this a churn if there are no further comments? Thanks! ... I just spotted the patches in -next, strange I didn't get an

On Fri, 21 Aug 2020 10:45:33 +0200 David Hildenbrand <david at redhat.com> wrote: > On 21.08.20 10:31, David Hildenbrand wrote: > > On 16.08.20 14:53, David Hildenbrand wrote: > >> For 5.10. Patch #1-#4,#6 have RBs or ACKs, patch #5 is virtio-mem stuff > >> maintained by me. This should go via the -mm tree. > >> > > > > @Andrew, can we give

On 21.08.20 10:31, David Hildenbrand wrote: > On 16.08.20 14:53, David Hildenbrand wrote: >> For 5.10. Patch #1-#4,#6 have RBs or ACKs, patch #5 is virtio-mem stuff >> maintained by me. This should go via the -mm tree. >> > > @Andrew, can we give this a churn if there are no further comments? Thanks! ... I just spotted the patches in -next, strange I didn't get an

...n 07/28/20 at 04:07pm, David Hildenbrand wrote: >> On 28.07.20 15:48, Baoquan He wrote: >>> On 06/30/20 at 04:26pm, David Hildenbrand wrote: >>>> Let's move the split comment regarding bootmem allocations and memory >>>> holes, especially in the context of ZONE_MOVABLE, to the PageReserved() >>>> check. >>>> >>>> Cc: Andrew Morton <akpm at linux-foundation.org> >>>> Cc: Michal Hocko <mhocko at suse.com> >>>> Cc: Michael S. Tsirkin <mst at redhat.com> >>>> Signed-off-by:...