From patchwork Thu Aug 15 12:11:02 2019 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: "Leizhen \(ThunderTown\)" X-Patchwork-Id: 171433 Delivered-To: patch@linaro.org Received: by 2002:a92:d204:0:0:0:0:0 with SMTP id y4csp2103501ily; Thu, 15 Aug 2019 05:12:00 -0700 (PDT) X-Google-Smtp-Source: APXvYqzcpJnIc05wJvlmj+N1JfpMH7NgKIySO7t3PM38hljEGxYRRK/dlFK319wVU1cap+IGofPF X-Received: by 2002:a17:902:b111:: with SMTP id q17mr458779plr.177.1565871120574; Thu, 15 Aug 2019 05:12:00 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1565871120; cv=none; d=google.com; s=arc-20160816; b=ItOV5fomgoU6jwwftbfbFTjKwMDuFUBMa9tvK+7bxkT9QiW/VLWdfQoJLPFIqfOJJp SmrfZ3Dl/UtxOzRD3d3iC3fimdKo1Sf25ysUPTYx2sCmDwMTp2O5F4yjv5ewTomCbc/t I7aVqjDI/FlhqaH/I7vQx/qzroO2tlyfKAfyzOEYXGhLxU4xYHENSoUg+BOM2ZHMZ7+K /0kfXmcPQwGG8+jjVB/VvlcZBuUxYPVovRDvs90SeXtqYnaNyXP5QdXmQp1FNj2mWDnR HuvQwSxKuQLoB2PrOdheS6jpMYrt8rh5qMY4En1vetZO73wDkWqAXLCvmscU0FJ2ioZL lu6w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :message-id:date:subject:cc:to:from; bh=mbLf2mae1OjkRKT3Hf+cqeVjinv27xyn20RGAiBvh1c=; b=tFV4gzpa4Oa14MaJfLWq9INKQj9srIV39xM++GhnAAQUYsP3toEgZsTuhDIie/s6vF Ij3cPSLpnj+oTiSjyvkiScqMUvuDABwVsqbW0oWWO8fZqE/S+oGHFiAi6/jd9+SrUteC BZSKfoRkw/jcgb1YrO/rme2MGxZ2lv4q/ZCL3gm0EgVF1kovg1XeIN0YRtxy5B2XP+xO p0olF3gGsHUrxmgs6hxhgzlCsT4GrjFsDyOqFEV/myT3nRBm5Tkr50xPN5Ts1nhiQ9Qs PfcS/SpetEwLDiYKfce+HP/I9LF4huevgKZZZoLNcKKCMx/L7me4XoEc0IJSALLJDTwv mlTw== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id s1si886210pjc.33.2019.08.15.05.12.00; Thu, 15 Aug 2019 05:12:00 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1731727AbfHOML7 (ORCPT + 28 others); Thu, 15 Aug 2019 08:11:59 -0400 Received: from szxga05-in.huawei.com ([45.249.212.191]:4279 "EHLO huawei.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1726865AbfHOML5 (ORCPT ); Thu, 15 Aug 2019 08:11:57 -0400 Received: from DGGEMS404-HUB.china.huawei.com (unknown [172.30.72.59]) by Forcepoint Email with ESMTP id 3F05632DDAE6107C412A; Thu, 15 Aug 2019 20:11:40 +0800 (CST) Received: from HGHY4L002753561.china.huawei.com (10.133.215.186) by DGGEMS404-HUB.china.huawei.com (10.3.19.204) with Microsoft SMTP Server id 14.3.439.0; Thu, 15 Aug 2019 20:11:32 +0800 From: Zhen Lei To: Jean-Philippe Brucker , "Jean-Philippe Brucker" , John Garry , "Robin Murphy" , Will Deacon , Joerg Roedel , iommu , Omer Peleg , Adam Morrison , Shaohua Li , Ben Serebrin , David Woodhouse , linux-arm-kernel , linux-kernel CC: Zhen Lei Subject: [PATCH v2 0/2] iommu/iova: enhance the rcache optimization Date: Thu, 15 Aug 2019 20:11:02 +0800 Message-ID: <20190815121104.29140-1-thunder.leizhen@huawei.com> X-Mailer: git-send-email 2.21.0.windows.1 MIME-Version: 1.0 X-Originating-IP: [10.133.215.186] X-CFilter-Loop: Reflected Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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