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

David Hildenbrand posted 4 patches 2 years, 6 months ago
drivers/virtio/virtio_mem.c | 168 ++++++++++++++++++++++++------------
1 file changed, 112 insertions(+), 56 deletions(-)
[PATCH v1 0/4] virtio-mem: memory unplug/offlining related cleanups
Posted by David Hildenbrand 2 years, 6 months ago
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
-- 
2.41.0
Re: [PATCH v1 0/4] virtio-mem: memory unplug/offlining related cleanups
Posted by Michael S. Tsirkin 2 years, 6 months ago
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
Re: [PATCH v1 0/4] virtio-mem: memory unplug/offlining related cleanups
Posted by David Hildenbrand 2 years, 6 months ago
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.

-- 
Cheers,

David / dhildenb