Received: by 2002:a05:6358:bb9e:b0:b9:5105:a5b4 with SMTP id df30csp3821959rwb; Mon, 5 Sep 2022 20:07:24 -0700 (PDT) X-Google-Smtp-Source: AA6agR7Ztra2fPrd2AGIU879EMW8mUVWwjDzlG9MEvMKrgxAlgqh7zH26qU0hEO+1jnRT0LB8R9q X-Received: by 2002:a17:907:75db:b0:741:4155:b52f with SMTP id jl27-20020a17090775db00b007414155b52fmr31818483ejc.638.1662433644270; Mon, 05 Sep 2022 20:07:24 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1662433644; cv=none; d=google.com; s=arc-20160816; b=0905QX8sHxYchLvipMpMnZ4G6UvmdjfiZia/R8pyAZgZwdT7MjXe0KtD1KuDPsv83A Ragl1vxj+tHL4VGPdzaPOn8fNHYf5u2cceCaNXE2snm9EghcrOzq4I06Cn1hEWyvSyVq tbFVXeab9WZ9plJ3Y8CaljnOBAA+TZMuXJpt5yn+B7O2cckayAPveEk9n+ReRHnzAaxo zSvNqMTOFZU1qnuaPCG/lfhLGGHAIDaa8zoglfgfQAp6z5WscxCNEYa7wh6qfAjSgH0f aZnh/pOOyrQzuqiE8sWadSAUMACy/yCv4AC/isDG2hj9avPuE3nhTeGGkPQ/3l6Xq9Ae TEAA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :message-id:date:subject:cc:to:from; bh=zLwyEeA9fSA92nIghPMEhDsISF84h59wW38+Tv9q5ig=; b=DPYzSd1BjgK74Rof/eZAAEpLKKTFqFxm6grlDtL9ZCC+F2O5SRfX9Dy1uwJWiwirZ3 YoZtTCiRagzpgyR0MwNvP5EOtR9n0OEgaxhpyxjxV4hHsF36pityfXAGtdGpuzIw1jA1 yQGCT/2qUyLR/CnRDzeskeo3c+osk00/rTX3l+brJA0HSK8mambB1tbK/deOzrucErcm LzDIc+NLGHGYJ1na+34vA3BeI5R73HGdZ79pn65F1ujqROXB4NIZWpR0bc+HY9Xt8suf GjYT8BJaRUq58sFlieuRxQzkbEaMm8KE33NESgj+OgekDJSmnFLCfQ4yzsIxBvrnI3ll DAHw== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=huawei.com Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id s20-20020aa7d794000000b0043e8b2ed68esi1663539edq.605.2022.09.05.20.06.59; Mon, 05 Sep 2022 20:07:24 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=huawei.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S237251AbiIFClG (ORCPT + 99 others); Mon, 5 Sep 2022 22:41:06 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:53666 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S236847AbiIFClF (ORCPT ); Mon, 5 Sep 2022 22:41:05 -0400 Received: from szxga01-in.huawei.com (szxga01-in.huawei.com [45.249.212.187]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id ADDF665555 for ; Mon, 5 Sep 2022 19:41:03 -0700 (PDT) Received: from dggpemm500024.china.huawei.com (unknown [172.30.72.54]) by szxga01-in.huawei.com (SkyGuard) with ESMTP id 4MM8hP0FfLznV6N; Tue, 6 Sep 2022 10:38:29 +0800 (CST) Received: from dggpemm500002.china.huawei.com (7.185.36.229) by dggpemm500024.china.huawei.com (7.185.36.203) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2375.24; Tue, 6 Sep 2022 10:40:59 +0800 Received: from localhost.localdomain (10.175.112.125) by dggpemm500002.china.huawei.com (7.185.36.229) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2375.24; Tue, 6 Sep 2022 10:40:58 +0800 From: Chen Wandun To: , , , CC: , Subject: [PATCH] iommu/dma: speedup memory allocation in __iommu_dma_alloc_pages Date: Tue, 6 Sep 2022 10:39:02 +0800 Message-ID: <20220906023902.133103-1-chenwandun@huawei.com> X-Mailer: git-send-email 2.25.1 MIME-Version: 1.0 Content-Transfer-Encoding: 7BIT Content-Type: text/plain; charset=US-ASCII X-Originating-IP: [10.175.112.125] X-ClientProxiedBy: dggems706-chm.china.huawei.com (10.3.19.183) To dggpemm500002.china.huawei.com (7.185.36.229) X-CFilter-Loop: Reflected X-Spam-Status: No, score=-4.2 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_MED, SPF_HELO_NONE,SPF_PASS,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org We found kcompactd was excessively running in Android, after some debug, found some order-9 allocations in iommu/dma. It splits contiguous page to single page in dma allocation, that means it is not necessary to alloc contiguous page, what is more, allocation for high order may cause direct memory reclaim and compaction, result in poor performance. In this patch, try to alloc memory by alloc_pages_bulk_array_node first, speedup memory allocation by saving unnecessary direct memory reclaim and compaction, fallback to original path when failed, beside remove __GFP_DIRECT_RECLAIM for costly order. Signed-off-by: Chen Wandun --- drivers/iommu/dma-iommu.c | 11 ++++++++++- 1 file changed, 10 insertions(+), 1 deletion(-) diff --git a/drivers/iommu/dma-iommu.c b/drivers/iommu/dma-iommu.c index f90251572a5d..b8463934d806 100644 --- a/drivers/iommu/dma-iommu.c +++ b/drivers/iommu/dma-iommu.c @@ -720,7 +720,7 @@ static struct page **__iommu_dma_alloc_pages(struct device *dev, unsigned int count, unsigned long order_mask, gfp_t gfp) { struct page **pages; - unsigned int i = 0, nid = dev_to_node(dev); + unsigned int i, nid = dev_to_node(dev); order_mask &= (2U << MAX_ORDER) - 1; if (!order_mask) @@ -736,6 +736,11 @@ static struct page **__iommu_dma_alloc_pages(struct device *dev, /* It makes no sense to muck about with huge pages */ gfp &= ~__GFP_COMP; + i = alloc_pages_bulk_array_node(gfp, nid, count, pages); + if (count == i) + return pages; + count -= i; + while (count) { struct page *page = NULL; unsigned int order_size; @@ -753,6 +758,10 @@ static struct page **__iommu_dma_alloc_pages(struct device *dev, order_size = 1U << order; if (order_mask > order_size) alloc_flags |= __GFP_NORETRY; + + if (order > PAGE_ALLOC_COSTLY_ORDER) + alloc_flags &= ~__GFP_DIRECT_RECLAIM; + page = alloc_pages_node(nid, alloc_flags, order); if (!page) continue; -- 2.25.1