lkml.org 
[lkml]   [2011]   [Nov]   [11]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH v4 2/7] iommu/core: split mapping to page sizes as supported by the hardware
On 11/11/2011 5:24 AM, Joerg Roedel wrote:
> On Thu, Nov 10, 2011 at 01:12:00PM -0800, Stepan Moskovchenko wrote:
>> I have been experimenting with an iommu_map_range call, which maps a
>> given scatterlist of discontiguous physical pages into a contiguous
>> virtual region at a given IOVA. This has some performance advantages
>> over just calling iommu_map iteratively. First, it reduces the
>> amount of table walking / calculation needed for mapping each page,
>> given how you know that all the pages will be mapped into a single
>> virtually-contiguous region (so in most cases, the first-level table
>> calculation can be reused). Second, it allows one to defer the TLB
>> (and sometimes cache) maintenance operations until the entire
>> scatterlist has been mapped, rather than doing a TLB invalidate
>> after mapping each page, as would have been the case if iommu_map
>> were just being called from within a loop. Granted, just using
>> iommu_map many times may be acceptable on the slow path, but I have
>> seen significant performance gains when using this approach on the
>> fast path.
> Yes, from a performance point-of-view that makes sense, as an addition
> to the existing iommu_map interface. Are the pages in the list allowed
> to have different page-sizes?
>
>
> Joerg
>

Hello

Yes, the scatterlist is allowed to have different page sizes. But, they
are required to have a length that is a multiple of 4K. If a page in the
list is bigger than 4K, the code will iteratively map it with 4K pages.
I suppose based on how my implementation is written, it would not be too
difficult to add checks for the proper length and VA/PA alignments, and
insert a 64K / 1M / 16M mapping if the alignment is lucky and the SG
item is big enough.

In my particular test case, even though the pages in the list might be
of different sizes, they are not guaranteed to be aligned properly and I
would most likely have to fall back on mapping them as multiple
consecutive 4K pages, anyway. But even despite this, having map_range to
consolidate a lot of the common operations into one call sill gives me a
nice speed boost.

I hadn't sent the patches out because this was all for my testing, but
would you be interested in me adding a map_range to the API? The
iommu_map_range call could even do a check if the ops supports a
.map_range, and fall back on calling iommu_map repeatedly if the driver
doesn't support this operation natively. In my code, the function takes
a domain, iova, scatterlist, length, and prot.

Steve


\
 
 \ /
  Last update: 2011-11-12 03:07    [W:0.096 / U:0.160 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site