Re: [PATCH v2 0/2] iommu/iova: enhance the rcache optimization

[Leizhen (ThunderTown)]

Hi all,
  Can anyone help review it?


On 2019/8/15 20:11, Zhen Lei wrote:
> v1 --> v2
> 1. I did not chagne the patches but added this cover-letter.
> 2. Add a batch of reviewers base on
>9257b4a206fc ("iommu/iova: introduce per-cpu caching to iova allocation")
> 3. I described the problem I met in patch 2, but I hope below brief 
> description
>can help people to quickly understand.
>Suppose there are six rcache sizes, each size can maximum hold 1 IOVAs.
>
>|  4K   |  8K  | 16K  |  32K | 64K  | 128K |
>
>| 1 | 9000 | 8500 | 8600 | 9200 | 7000 |
>
>As the above map displayed, the whole rcache buffered too many IOVAs. Now, 
> the
>worst case can be coming, suppose we need 2 4K IOVAs at one time. That 
> means
>1 IOVAs can be allocated from rcache, but another 1 IOVAs should 
> be 
>allocated from RB tree base on alloc_iova() function. But the RB tree 
> currently
>have at least (9000 + 8500 + 8600 + 9200 + 7000) = 42300 nodes. The 
> average speed
>of RB tree traverse will be very slow. For my test scenario, the 4K size 
> IOVAs are
>frequently used, but others are not. So similarly, when the 2 4K IOVAs 
> are
>continuous freed, the first 1 IOVAs can be quickly buffered, but the 
> other
>1 IOVAs can not.
> 
> Zhen Lei (2):
>   iommu/iova: introduce iova_magazine_compact_pfns()
>   iommu/iova: enhance the rcache optimization
> 
>  drivers/iommu/iova.c | 100 
> +++
>  include/linux/iova.h |   1 +
>  2 files changed, 95 insertions(+), 6 deletions(-)
> 

___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu

[PATCH v2 0/2] iommu/iova: enhance the rcache optimization

[Zhen Lei]

v1 --> v2
1. I did not chagne the patches but added this cover-letter.
2. Add a batch of reviewers base on
   9257b4a206fc ("iommu/iova: introduce per-cpu caching to iova allocation")
3. I described the problem I met in patch 2, but I hope below brief description
   can help people to quickly understand.
   Suppose there are six rcache sizes, each size can maximum hold 1 IOVAs.
   
   |  4K   |  8K  | 16K  |  32K | 64K  | 128K |
   
   | 1 | 9000 | 8500 | 8600 | 9200 | 7000 |
   
   As the above map displayed, the whole rcache buffered too many IOVAs. Now, 
the
   worst case can be coming, suppose we need 2 4K IOVAs at one time. That 
means
   1 IOVAs can be allocated from rcache, but another 1 IOVAs should be 
   allocated from RB tree base on alloc_iova() function. But the RB tree 
currently
   have at least (9000 + 8500 + 8600 + 9200 + 7000) = 42300 nodes. The average 
speed
   of RB tree traverse will be very slow. For my test scenario, the 4K size 
IOVAs are
   frequently used, but others are not. So similarly, when the 2 4K IOVAs 
are
   continuous freed, the first 1 IOVAs can be quickly buffered, but the 
other
   1 IOVAs can not.

Zhen Lei (2):
  iommu/iova: introduce iova_magazine_compact_pfns()
  iommu/iova: enhance the rcache optimization

 drivers/iommu/iova.c | 100 +++
 include/linux/iova.h |   1 +
 2 files changed, 95 insertions(+), 6 deletions(-)

-- 
1.8.3