lkml.org 
[lkml]   [2022]   [Jun]   [10]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
SubjectRe: [RFC PATCHES 1/2] iommu: Add RCU-protected page free support
From
On 2022/6/9 21:32, Jason Gunthorpe wrote:
> On Thu, Jun 09, 2022 at 02:19:06PM +0100, Robin Murphy wrote:
>
>> Is there a significant benefit to keeping both paths, or could we get away
>> with just always using RCU? Realistically, pagetable pages aren't likely to
>> be freed all that frequently, except perhaps at domain teardown, but that
>> shouldn't really be performance-critical, and I guess we could stick an RCU
>> sync point in iommu_domain_free() if we're really worried about releasing
>> larger quantities of pages back to the allocator ASAP?
>
> I think you are right, anything that uses the iommu_iotlb_gather may
> as well use RCU too.
>
> IIRC the allocators already know that RCU is often sitting on
> freed-memory and have some contigency to flush it out before OOMing,
> so nothing special should be needed.

Fair enough. How about below code?

static void pgtble_page_free_rcu(struct rcu_head *rcu)
{
struct page *page = container_of(rcu, struct page, rcu_head);

__free_pages(page, 0);
}

/*
* Free pages gathered in the freelist of iommu_iotlb_gather. Use RCU free
* way so that it's safe for lock-free page table walk.
*/
void iommu_free_iotlb_gather_pages(struct iommu_iotlb_gather *iotlb_gather)
{
struct page *page, *next;

list_for_each_entry_safe(page, next, &iotlb_gather->freelist,
lru) {
list_del(&page->lru);
call_rcu(&page->rcu_head, pgtble_page_free_rcu);
}
}

Best regards,
baolu

\
 
 \ /
  Last update: 2022-06-10 08:00    [W:0.040 / U:0.040 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site