All of lore.kernel.org
 help / color / mirror / Atom feed
From: Juan Quintela <quintela@redhat.com>
To: David Hildenbrand <david@redhat.com>
Cc: qemu-devel@nongnu.org, "Michael S. Tsirkin" <mst@redhat.com>,
	"Peter Xu" <peterx@redhat.com>,
	"Leonardo Bras" <leobras@redhat.com>,
	"Paolo Bonzini" <pbonzini@redhat.com>,
	"Philippe Mathieu-Daudé" <philmd@linaro.org>,
	"Peng Tao" <tao.peng@linux.alibaba.com>,
	"Mario Casquero" <mcasquer@redhat.com>
Subject: Re: [PATCH v2 2/4] virtio-mem: Skip most of virtio_mem_unplug_all() without plugged memory
Date: Thu, 06 Jul 2023 10:15:45 +0200	[thread overview]
Message-ID: <87fs61bglq.fsf@secure.mitica> (raw)
In-Reply-To: <20230706075612.67404-3-david@redhat.com> (David Hildenbrand's message of "Thu, 6 Jul 2023 09:56:07 +0200")

David Hildenbrand <david@redhat.com> wrote:
> Already when starting QEMU we perform one system reset that ends up
> triggering virtio_mem_unplug_all() with no actual memory plugged yet.
> That, in turn will trigger ram_block_discard_range() and perform some
> other actions that are not required in that case.
>
> Let's optimize virtio_mem_unplug_all() for the case that no memory is
> plugged. This will be beneficial for x-ignore-shared support as well.
>
> Tested-by: Mario Casquero <mcasquer@redhat.com>
> Signed-off-by: David Hildenbrand <david@redhat.com>

It works, so ...

Reviewed-by: Juan Quintela <quintela@redhat.com>

>      RAMBlock *rb = vmem->memdev->mr.ram_block;
>  
> -    if (virtio_mem_is_busy()) {
> -        return -EBUSY;
> -    }
> -
> -    if (ram_block_discard_range(rb, 0, qemu_ram_get_used_length(rb))) {
> -        return -EBUSY;
> -    }
> -    virtio_mem_notify_unplug_all(vmem);
> -
> -    bitmap_clear(vmem->bitmap, 0, vmem->bitmap_size);
>      if (vmem->size) {
> +        if (virtio_mem_is_busy()) {
> +            return -EBUSY;

I see that the only way that virtio_men_is_busy() is true is if we are
in the middle of a migration.  In the case that vmem is 0, we don't
care.  So we are good.



> +        }
> +        if (ram_block_discard_range(rb, 0, qemu_ram_get_used_length(rb))) {
> +            return -EBUSY;
> +        }

Nothing to discard, so also good.

> +        virtio_mem_notify_unplug_all(vmem);

Nothing to notify, so also good.

> +        bitmap_clear(vmem->bitmap, 0, vmem->bitmap_size);
>          vmem->size = 0;
>          notifier_list_notify(&vmem->size_change_notifiers, &vmem->size);
>      }
> +
>      trace_virtio_mem_unplugged_all();
>      virtio_mem_resize_usable_region(vmem, vmem->requested_size, true);
>      return 0;

Once that we are here.  Do you remember _why_ do we allow virtio-mem
plug/unplug in the middle of a migration.

We forbid to plug/unplug everything else.  Why do we need to plug/unplug
virtio-mem during migration?

Thanks, Juan.



  reply	other threads:[~2023-07-06  8:16 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-07-06  7:56 [PATCH v2 0/4] virtio-mem: Support "x-ignore-shared" migration David Hildenbrand
2023-07-06  7:56 ` [PATCH v2 1/4] softmmu/physmem: Warn with ram_block_discard_range() on MAP_PRIVATE file mapping David Hildenbrand
2023-07-06  8:10   ` Juan Quintela
2023-07-06  8:31     ` David Hildenbrand
2023-07-06 13:20       ` Juan Quintela
2023-07-06 13:23         ` David Hildenbrand
2023-07-06  8:49   ` David Hildenbrand
2023-10-18  3:02   ` Xiaoyao Li
2023-10-18  7:42     ` David Hildenbrand
2023-10-18  9:02       ` Xiaoyao Li
2023-10-18  9:26         ` David Hildenbrand
2023-10-18 16:27           ` Xiaoyao Li
2023-10-19  8:26             ` David Hildenbrand
2023-10-19  9:26               ` Xiaoyao Li
2023-10-19  9:43                 ` David Hildenbrand
2023-07-06  7:56 ` [PATCH v2 2/4] virtio-mem: Skip most of virtio_mem_unplug_all() without plugged memory David Hildenbrand
2023-07-06  8:15   ` Juan Quintela [this message]
2023-07-06  8:38     ` David Hildenbrand
2023-07-06 13:27       ` Juan Quintela
2023-07-06  7:56 ` [PATCH v2 3/4] migration/ram: Expose ramblock_is_ignored() as migrate_ram_is_ignored() David Hildenbrand
2023-07-06  8:16   ` Juan Quintela
2023-07-06  7:56 ` [PATCH v2 4/4] virtio-mem: Support "x-ignore-shared" migration David Hildenbrand
2023-07-06 11:06   ` Juan Quintela
2023-07-06 11:27     ` David Hildenbrand
2023-07-06 11:59   ` Juan Quintela
2023-07-06 14:03 ` [PATCH v2 0/4] " Michael S. Tsirkin
2023-07-07 12:21   ` David Hildenbrand

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87fs61bglq.fsf@secure.mitica \
    --to=quintela@redhat.com \
    --cc=david@redhat.com \
    --cc=leobras@redhat.com \
    --cc=mcasquer@redhat.com \
    --cc=mst@redhat.com \
    --cc=pbonzini@redhat.com \
    --cc=peterx@redhat.com \
    --cc=philmd@linaro.org \
    --cc=qemu-devel@nongnu.org \
    --cc=tao.peng@linux.alibaba.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.