From: Peter Xu <peterx@redhat.com>
To: "Emilio G. Cota" <cota@braap.org>
Cc: qemu-devel@nongnu.org, Jason Wang <jasowang@redhat.com>,
Alex Williamson <alex.williamson@redhat.com>,
Jintack Lim <jintack@cs.columbia.edu>,
"Michael S . Tsirkin" <mst@redhat.com>
Subject: Re: [Qemu-devel] [PATCH 03/10] intel-iommu: add iommu lock
Date: Thu, 26 Apr 2018 13:45:22 +0800 [thread overview]
Message-ID: <20180426054522.GP9036@xz-mi> (raw)
In-Reply-To: <20180425162658.GA9204@flamenco>
On Wed, Apr 25, 2018 at 12:26:58PM -0400, Emilio G. Cota wrote:
> On Wed, Apr 25, 2018 at 12:51:22 +0800, Peter Xu wrote:
> > Add a per-iommu big lock to protect IOMMU status. Currently the only
> > thing to be protected is the IOTLB cache, since that can be accessed
> > even without BQL, e.g., in IO dataplane.
>
> Is the added lock going to protect anything else beyond a g_hash_table?
It's only for that now. Maybe there can be other candidates.
> If not, did you consider using qht instead of the lock + hash table?
> It would give you lockless lookups as well as scalable updates.
Thanks for pointing that out. I didn't even know that we have such a
nice hash there. :) Though for this series I would still prefer to
keep the mutex way as is for now.
Firstly, I'd better fix the problem first before considering
performance - after all this series is not really persuing for
performance but fixing holes. So we can have follow up works for QHT
convertions. Meanwhile, IOTLB is a bit special in that it might
really update more often than we thought, so I'm not really sure
whether a RCU-based hash would bring better performance. This is even
not considering the fact that Linux guest intel-iommu driver will do
more tricks (like frequently flushing IOTLBs) to make the update much
more than usual.
But again, the suggestion is valid and it worths further
investigations to make sure my understandings are correct.
>
> [Sorry if my question isn't relevant, I am not familiar with
> this code and just briefly skimmed over this series.
It's of course relevant. Thanks for your input!
--
Peter Xu
next prev parent reply other threads:[~2018-04-26 5:45 UTC|newest]
Thread overview: 52+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-04-25 4:51 [Qemu-devel] [PATCH 00/10] intel-iommu: nested vIOMMU, cleanups, bug fixes Peter Xu
2018-04-25 4:51 ` [Qemu-devel] [PATCH 01/10] intel-iommu: send PSI always even if across PDEs Peter Xu
2018-04-25 4:51 ` [Qemu-devel] [PATCH 02/10] intel-iommu: remove IntelIOMMUNotifierNode Peter Xu
2018-04-25 4:51 ` [Qemu-devel] [PATCH 03/10] intel-iommu: add iommu lock Peter Xu
2018-04-25 16:26 ` Emilio G. Cota
2018-04-26 5:45 ` Peter Xu [this message]
2018-04-27 5:13 ` Jason Wang
2018-04-27 6:26 ` Peter Xu
2018-04-27 7:19 ` Tian, Kevin
2018-04-27 9:53 ` Peter Xu
2018-04-28 1:54 ` Tian, Kevin
2018-04-28 1:43 ` Jason Wang
2018-04-28 2:24 ` Peter Xu
2018-04-28 2:42 ` Jason Wang
2018-04-28 3:06 ` Peter Xu
2018-04-28 3:11 ` Jason Wang
2018-04-28 3:14 ` Peter Xu
2018-04-28 3:16 ` Jason Wang
2018-04-30 7:22 ` Paolo Bonzini
2018-04-30 7:20 ` Paolo Bonzini
2018-05-03 5:39 ` Peter Xu
2018-04-25 4:51 ` [Qemu-devel] [PATCH 04/10] intel-iommu: only do page walk for MAP notifiers Peter Xu
2018-04-25 4:51 ` [Qemu-devel] [PATCH 05/10] intel-iommu: introduce vtd_page_walk_info Peter Xu
2018-04-25 4:51 ` [Qemu-devel] [PATCH 06/10] intel-iommu: pass in address space when page walk Peter Xu
2018-04-25 4:51 ` [Qemu-devel] [PATCH 07/10] util: implement simple interval tree logic Peter Xu
2018-04-27 5:53 ` Jason Wang
2018-04-27 6:27 ` Peter Xu
2018-05-03 7:10 ` Peter Xu
2018-05-03 7:21 ` Jason Wang
2018-05-03 7:30 ` Peter Xu
2018-04-25 4:51 ` [Qemu-devel] [PATCH 08/10] intel-iommu: maintain per-device iova ranges Peter Xu
2018-04-27 6:07 ` Jason Wang
2018-04-27 6:34 ` Peter Xu
2018-04-27 7:02 ` Tian, Kevin
2018-04-27 7:28 ` Peter Xu
2018-04-27 7:44 ` Tian, Kevin
2018-04-27 9:55 ` Peter Xu
2018-04-27 11:40 ` Peter Xu
2018-04-27 23:37 ` Tian, Kevin
2018-05-03 6:04 ` Peter Xu
2018-05-03 7:20 ` Jason Wang
2018-05-03 7:28 ` Peter Xu
2018-05-03 7:43 ` Jason Wang
2018-05-03 7:53 ` Peter Xu
2018-05-03 9:22 ` Jason Wang
2018-05-03 9:53 ` Peter Xu
2018-05-03 12:01 ` Peter Xu
2018-04-28 1:49 ` Jason Wang
2018-04-25 4:51 ` [Qemu-devel] [PATCH 09/10] intel-iommu: don't unmap all for shadow page table Peter Xu
2018-04-25 4:51 ` [Qemu-devel] [PATCH 10/10] intel-iommu: remove notify_unmap for page walk Peter Xu
2018-04-25 5:05 ` [Qemu-devel] [PATCH 00/10] intel-iommu: nested vIOMMU, cleanups, bug fixes no-reply
2018-04-25 5:34 ` Peter Xu
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=20180426054522.GP9036@xz-mi \
--to=peterx@redhat.com \
--cc=alex.williamson@redhat.com \
--cc=cota@braap.org \
--cc=jasowang@redhat.com \
--cc=jintack@cs.columbia.edu \
--cc=mst@redhat.com \
--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).