From: Peter Xu <peterx@redhat.com>
To: hongmainquan <hongmianquan@bytedance.com>
Cc: qemu-devel@nongnu.org, philmd@linaro.org, david@redhat.com,
Paolo Bonzini <pbonzini@redhat.com>
Subject: Re: [External] Re: [PATCH] memory: avoid updating ioeventfds for some address_space
Date: Thu, 27 Jul 2023 10:36:06 -0400 [thread overview]
Message-ID: <ZMKA1n+8tmQC4JLA@x1n> (raw)
In-Reply-To: <9343c790-7fa6-1f1e-ed1c-2f350de44ec9@bytedance.com>
On Thu, Jul 27, 2023 at 09:23:34PM +0800, hongmainquan wrote:
>
>
> 在 2023/7/27 8:53 下午, Peter Xu 写道:
> > On Thu, Jul 27, 2023 at 11:59:43AM +0800, hongmainquan wrote:
> > >
> > >
> > > 在 2023/7/27 1:45 上午, Peter Xu 写道:
> > > > On Tue, Jul 25, 2023 at 07:20:37PM +0800, hongmianquan wrote:
> > > > > When updating ioeventfds, we need to iterate all address spaces,
> > > > > but some address spaces do not register eventfd_add|del call when
> > > > > memory_listener_register() and they do nothing when updating ioeventfds.
> > > > > So we can skip these AS in address_space_update_ioeventfds().
> > > > >
> > > > > The overhead of memory_region_transaction_commit() can be significantly
> > > > > reduced. For example, a VM with 8 vhost net devices and each one has
> > > > > 64 vectors, can reduce the time spent on memory_region_transaction_commit by 20%.
> > > > >
> > > > > Signed-off-by: hongmianquan <hongmianquan@bytedance.com>
> > > >
> > > > Reviewed-by: Peter Xu <peterx@redhat.com>
> > > >
> > > > Should be for 8.2, though. Please always copy Paolo for memory related
> > > > patches. I hope Paolo can see this.
> > > >
> > > Thanks, I hope so. Also, I'm not quite sure what 'Should be for 8.2' means.
> > > Does it imply that there will be changes to this logic after version 8.2?
> >
> > See:
> >
> > https://wiki.qemu.org/Planning/8.1
> >
> > We're already right before 8.1-rc2 release, perf patch isn't normally the
> > target of this phase.
> >
> > Thanks,
> >
> Understood. Hope for some suggestions from you.
No further suggestion from my side. You can just keep an eye on this patch
after the 8.1 release - it probably just won't get merged before that.
Some maintainers prefer a resend after the release, but many don't. It's
optional in this case I think.
Thanks,
--
Peter Xu
next prev parent reply other threads:[~2023-07-27 14:54 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-07-25 11:20 [PATCH] memory: avoid updating ioeventfds for some address_space hongmianquan
2023-07-26 17:45 ` Peter Xu
2023-07-27 3:59 ` [External] " hongmainquan
2023-07-27 12:53 ` Peter Xu
2023-07-27 13:23 ` hongmainquan
2023-07-27 14:36 ` Peter Xu [this message]
2023-07-27 15:01 ` hongmainquan
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=ZMKA1n+8tmQC4JLA@x1n \
--to=peterx@redhat.com \
--cc=david@redhat.com \
--cc=hongmianquan@bytedance.com \
--cc=pbonzini@redhat.com \
--cc=philmd@linaro.org \
--cc=qemu-devel@nongnu.org \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).