| Message ID | 20190815121104.29140-1-thunder.leizhen@huawei.com |
|---|---|
| Headers | show |
| Series | iommu/iova: enhance the rcache optimization | expand |
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 10000 IOVAs. > -------------------------------------------- > | 4K | 8K | 16K | 32K | 64K | 128K | > -------------------------------------------- > | 10000 | 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 20000 4K IOVAs at one time. That means > 10000 IOVAs can be allocated from rcache, but another 10000 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 20000 4K IOVAs are > continuous freed, the first 10000 IOVAs can be quickly buffered, but the other > 10000 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(-) >
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 10000 IOVAs. -------------------------------------------- | 4K | 8K | 16K | 32K | 64K | 128K | -------------------------------------------- | 10000 | 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 20000 4K IOVAs at one time. That means 10000 IOVAs can be allocated from rcache, but another 10000 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 20000 4K IOVAs are continuous freed, the first 10000 IOVAs can be quickly buffered, but the other 10000 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