From: Boris Brezillon <boris.brezillon@collabora.com>
To: Jason Gunthorpe <jgg@nvidia.com>
Cc: "Robin Murphy" <robin.murphy@arm.com>,
"Joerg Roedel" <joro@8bytes.org>,
iommu@lists.linux.dev, "Will Deacon" <will@kernel.org>,
linux-arm-kernel@lists.infradead.org,
"Rob Clark" <robdclark@gmail.com>,
"Gaurav Kohli" <quic_gkohli@quicinc.com>,
"Steven Price" <steven.price@arm.com>,
"Pasha Tatashin" <pasha.tatashin@soleen.com>,
"Sean Christopherson" <seanjc@google.com>,
"Alex Williamson" <alex.williamson@redhat.com>,
"Joao Martins" <joao.m.martins@oracle.com>,
"Krzysztof Wilczyński" <kwilczynski@kernel.org>
Subject: Re: Light summary of LPC discussions on io page table
Date: Thu, 23 Nov 2023 16:48:43 +0100 [thread overview]
Message-ID: <20231123164843.040a2c67@collabora.com> (raw)
In-Reply-To: <20231123151118.GA436110@nvidia.com>
Hi Jason,
On Thu, 23 Nov 2023 11:11:18 -0400
Jason Gunthorpe <jgg@nvidia.com> wrote:
> On Thu, Nov 23, 2023 at 09:51:41AM +0100, Boris Brezillon wrote:
>
> > Can these people please raise their voice here? Or maybe LPC's IOMMU
> > discussions were summarized somewhere in an email sent to the IOMMU ML,
> > where we could discuss that, instead of this thread.
>
> I think we are using session recordings mostly these days? I have a
> bunch of people interested - I'm going to work to launch another group
> project to tackle this. Maybe in Jan.
>
> The recordings are not broken up yet, but here is the master:
>
> https://www.youtube.com/live/vO2mAM8wOvU
>
> Pasha's talk is first at 2:21, and there was some discussion in the
> room that may be hard to hear including the use of RCU and the
> refcount. Pasha is interested in solving the memory waste his VFIO
> application causes which is basically an algorithmic problem inside
> the io page table. There was also some side discussion about
> optimizations. mm implements a batch free technique that could apply
> here too, and a batch alloc is also potentially interesting.
>
> My talk starts at 3:11 and we have another discussion later around
> this issue in the context of dirty tracking optimization. Joao has
> written and shared some code for what is concerning there in an
> earlier email Sean C is the voice at the back sharing the KVM
> learnings that getting to a common implementation is highly
> recommended
>
> I had an interesting hallway discussion about a use case for bringing
> back the old VFIO type 1.0 huge page split behavior and implementing
> it in every enterprise iommu.
>
> Then we have this DRM need, which I've come to think of as a
> guarenteed map without a table level allocate.
>
> These need touching all the "enterprise" focused page table
> formats. There are so many now, doing the algorithm work 5-7 times is
> not reasonable. A common radix algorithm and a more complex shared
> implementation relying on RCU is the direction I want to head in. mm
> shows a template how to achieve this, and I have some rough ideas to
> explore.
Thanks for pulling this together. I'll try to watch the video and make
sense of what's explained there. I'll get back to you if I have
questions.
Regards,
Boris
WARNING: multiple messages have this Message-ID (diff)
From: Boris Brezillon <boris.brezillon@collabora.com>
To: Jason Gunthorpe <jgg@nvidia.com>
Cc: "Robin Murphy" <robin.murphy@arm.com>,
"Joerg Roedel" <joro@8bytes.org>,
iommu@lists.linux.dev, "Will Deacon" <will@kernel.org>,
linux-arm-kernel@lists.infradead.org,
"Rob Clark" <robdclark@gmail.com>,
"Gaurav Kohli" <quic_gkohli@quicinc.com>,
"Steven Price" <steven.price@arm.com>,
"Pasha Tatashin" <pasha.tatashin@soleen.com>,
"Sean Christopherson" <seanjc@google.com>,
"Alex Williamson" <alex.williamson@redhat.com>,
"Joao Martins" <joao.m.martins@oracle.com>,
"Krzysztof Wilczyński" <kwilczynski@kernel.org>
Subject: Re: Light summary of LPC discussions on io page table
Date: Thu, 23 Nov 2023 16:48:43 +0100 [thread overview]
Message-ID: <20231123164843.040a2c67@collabora.com> (raw)
In-Reply-To: <20231123151118.GA436110@nvidia.com>
Hi Jason,
On Thu, 23 Nov 2023 11:11:18 -0400
Jason Gunthorpe <jgg@nvidia.com> wrote:
> On Thu, Nov 23, 2023 at 09:51:41AM +0100, Boris Brezillon wrote:
>
> > Can these people please raise their voice here? Or maybe LPC's IOMMU
> > discussions were summarized somewhere in an email sent to the IOMMU ML,
> > where we could discuss that, instead of this thread.
>
> I think we are using session recordings mostly these days? I have a
> bunch of people interested - I'm going to work to launch another group
> project to tackle this. Maybe in Jan.
>
> The recordings are not broken up yet, but here is the master:
>
> https://www.youtube.com/live/vO2mAM8wOvU
>
> Pasha's talk is first at 2:21, and there was some discussion in the
> room that may be hard to hear including the use of RCU and the
> refcount. Pasha is interested in solving the memory waste his VFIO
> application causes which is basically an algorithmic problem inside
> the io page table. There was also some side discussion about
> optimizations. mm implements a batch free technique that could apply
> here too, and a batch alloc is also potentially interesting.
>
> My talk starts at 3:11 and we have another discussion later around
> this issue in the context of dirty tracking optimization. Joao has
> written and shared some code for what is concerning there in an
> earlier email Sean C is the voice at the back sharing the KVM
> learnings that getting to a common implementation is highly
> recommended
>
> I had an interesting hallway discussion about a use case for bringing
> back the old VFIO type 1.0 huge page split behavior and implementing
> it in every enterprise iommu.
>
> Then we have this DRM need, which I've come to think of as a
> guarenteed map without a table level allocate.
>
> These need touching all the "enterprise" focused page table
> formats. There are so many now, doing the algorithm work 5-7 times is
> not reasonable. A common radix algorithm and a more complex shared
> implementation relying on RCU is the direction I want to head in. mm
> shows a template how to achieve this, and I have some rough ideas to
> explore.
Thanks for pulling this together. I'll try to watch the video and make
sense of what's explained there. I'll get back to you if I have
questions.
Regards,
Boris
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2023-11-23 15:48 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-11-23 15:11 Light summary of LPC discussions on io page table Jason Gunthorpe
2023-11-23 15:11 ` Jason Gunthorpe
2023-11-23 15:48 ` Boris Brezillon [this message]
2023-11-23 15:48 ` Boris Brezillon
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=20231123164843.040a2c67@collabora.com \
--to=boris.brezillon@collabora.com \
--cc=alex.williamson@redhat.com \
--cc=iommu@lists.linux.dev \
--cc=jgg@nvidia.com \
--cc=joao.m.martins@oracle.com \
--cc=joro@8bytes.org \
--cc=kwilczynski@kernel.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=pasha.tatashin@soleen.com \
--cc=quic_gkohli@quicinc.com \
--cc=robdclark@gmail.com \
--cc=robin.murphy@arm.com \
--cc=seanjc@google.com \
--cc=steven.price@arm.com \
--cc=will@kernel.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 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.