Light summary of LPC discussions on io page table

Light summary of LPC discussions on io page table

[Jason Gunthorpe]

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,
Jason

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: Light summary of LPC discussions on io page table

[Boris Brezillon]

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