mbox series

[v1,0/4] virtio-mem: memory unplug/offlining related cleanups

Message ID 20230713145551.2824980-1-david@redhat.com (mailing list archive)
Headers show
Series virtio-mem: memory unplug/offlining related cleanups | expand

Message

David Hildenbrand July 13, 2023, 2:55 p.m. UTC
Some cleanups+optimizations primarily around offline_and_remove_memory().

Patch #1 drops the "unsafe unplug" feature where we might get stuck in
offline_and_remove_memory() forever.

Patch #2 handles unexpected errors from offline_and_remove_memory() a bit
nicer.

Patch #3 handles the case where offline_and_remove_memory() failed and
we want to retry later to remove a completely unplugged Linux memory
block, to not have them waste memory forever.

Patch #4 something I had lying around for longer, which reacts faster
on config changes when unplugging memory.

Cc: "Michael S. Tsirkin" <mst@redhat.com>
Cc: Jason Wang <jasowang@redhat.com>
Cc: Xuan Zhuo <xuanzhuo@linux.alibaba.com>

David Hildenbrand (4):
  virtio-mem: remove unsafe unplug in Big Block Mode (BBM)
  virtio-mem: convert most offline_and_remove_memory() errors to -EBUSY
  virtio-mem: keep retrying on offline_and_remove_memory() errors in Sub
    Block Mode (SBM)
  virtio-mem: check if the config changed before fake offlining memory

 drivers/virtio/virtio_mem.c | 168 ++++++++++++++++++++++++------------
 1 file changed, 112 insertions(+), 56 deletions(-)


base-commit: 3f01e9fed8454dcd89727016c3e5b2fbb8f8e50c

Comments

Michael S. Tsirkin July 13, 2023, 3:03 p.m. UTC | #1
On Thu, Jul 13, 2023 at 04:55:47PM +0200, David Hildenbrand wrote:
> Some cleanups+optimizations primarily around offline_and_remove_memory().
> 
> Patch #1 drops the "unsafe unplug" feature where we might get stuck in
> offline_and_remove_memory() forever.
> 
> Patch #2 handles unexpected errors from offline_and_remove_memory() a bit
> nicer.
> 
> Patch #3 handles the case where offline_and_remove_memory() failed and
> we want to retry later to remove a completely unplugged Linux memory
> block, to not have them waste memory forever.
> 
> Patch #4 something I had lying around for longer, which reacts faster
> on config changes when unplugging memory.
> 
> Cc: "Michael S. Tsirkin" <mst@redhat.com>
> Cc: Jason Wang <jasowang@redhat.com>
> Cc: Xuan Zhuo <xuanzhuo@linux.alibaba.com>

This looks like something that's reasonable to put in this linux, right?
These are fixes even though they are for theoretical issues.

> David Hildenbrand (4):
>   virtio-mem: remove unsafe unplug in Big Block Mode (BBM)
>   virtio-mem: convert most offline_and_remove_memory() errors to -EBUSY
>   virtio-mem: keep retrying on offline_and_remove_memory() errors in Sub
>     Block Mode (SBM)
>   virtio-mem: check if the config changed before fake offlining memory
> 
>  drivers/virtio/virtio_mem.c | 168 ++++++++++++++++++++++++------------
>  1 file changed, 112 insertions(+), 56 deletions(-)
> 
> 
> base-commit: 3f01e9fed8454dcd89727016c3e5b2fbb8f8e50c
> -- 
> 2.41.0
David Hildenbrand July 14, 2023, 9:55 a.m. UTC | #2
On 13.07.23 17:03, Michael S. Tsirkin wrote:
> On Thu, Jul 13, 2023 at 04:55:47PM +0200, David Hildenbrand wrote:
>> Some cleanups+optimizations primarily around offline_and_remove_memory().
>>
>> Patch #1 drops the "unsafe unplug" feature where we might get stuck in
>> offline_and_remove_memory() forever.
>>
>> Patch #2 handles unexpected errors from offline_and_remove_memory() a bit
>> nicer.
>>
>> Patch #3 handles the case where offline_and_remove_memory() failed and
>> we want to retry later to remove a completely unplugged Linux memory
>> block, to not have them waste memory forever.
>>
>> Patch #4 something I had lying around for longer, which reacts faster
>> on config changes when unplugging memory.
>>
>> Cc: "Michael S. Tsirkin" <mst@redhat.com>
>> Cc: Jason Wang <jasowang@redhat.com>
>> Cc: Xuan Zhuo <xuanzhuo@linux.alibaba.com>
> 
> This looks like something that's reasonable to put in this linux, right?
> These are fixes even though they are for theoretical issues.

Yes, but these are not high-priority fixes+optimizations. So if you feel 
like we should be delaying them, fine with me.

On the other hand, getting them in now also shouldn't really hurt. 
Especially patch #1 might be better of just going in soner than later.