From patchwork Fri Sep 22 09:15:05 2023 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: "zhaoyang.huang" X-Patchwork-Id: 13395418 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id BDEA0CD4F33 for ; Fri, 22 Sep 2023 09:17:08 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:MIME-Version:Message-ID:Date:Subject:To :From:Reply-To:Cc:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References: List-Owner; bh=ciVvZRiN7JkaK29BpJhMHp+i60jBCB1bCf2LKIxV1Hg=; b=XiB55pbcp82nj/ 1gltX+4UiLOnhdrNcplvdeWePpK+XrflgSD1nYAUGULcYj2FH9n9TtxJf/kq0FZPhPWX/2Q6ppaFr TP7tK6INAKjwLzwQmFpf3rQFBDyKVvVRS2upJo/+al2E9TTtm3Dcq0Wx722ictJ2Bt7nvTnZRJUje 7E3u8k2BOwhqRzCVZ8s+IB2ePgQgYBqQQl1DOZGx1+LAMjppO60sxjFNuaGJmy4+M3vOqvn2V3ruf p1cIp27uW+wyZ2DIZMJI0bBrPjCRZ5zNaKbd5Pf6mekKstbvEVrHd3ts57nH7cFTpCbPzhnwFkPbl J04523a1kiL8XPRb/k6g==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.96 #2 (Red Hat Linux)) id 1qjcHD-008Xk8-0F; Fri, 22 Sep 2023 09:16:43 +0000 Received: from mx1.unisoc.com ([222.66.158.135] helo=SHSQR01.spreadtrum.com) by bombadil.infradead.org with esmtps (Exim 4.96 #2 (Red Hat Linux)) id 1qjcH4-008XeD-2y for linux-arm-kernel@lists.infradead.org; Fri, 22 Sep 2023 09:16:41 +0000 Received: from dlp.unisoc.com ([10.29.3.86]) by SHSQR01.spreadtrum.com with ESMTP id 38M9FBK6033971; Fri, 22 Sep 2023 17:15:11 +0800 (+08) (envelope-from zhaoyang.huang@unisoc.com) Received: from SHDLP.spreadtrum.com (bjmbx01.spreadtrum.com [10.0.64.7]) by dlp.unisoc.com (SkyGuard) with ESMTPS id 4RsRNP2mzdz2SdWY0; Fri, 22 Sep 2023 17:11:49 +0800 (CST) Received: from bj03382pcu01.spreadtrum.com (10.0.73.40) by BJMBX01.spreadtrum.com (10.0.64.7) with Microsoft SMTP Server (TLS) id 15.0.1497.23; Fri, 22 Sep 2023 17:15:10 +0800 From: "zhaoyang.huang" To: Russell King , Andrew Morton , Mike Rapoport , Matthew Wilcox , , , , Zhaoyang Huang , , Subject: [Resend PATCH] arch: arm: remove redundant clear_page when CONFIG_INIT_ON_ALLOC_DEFAULT_ON is on Date: Fri, 22 Sep 2023 17:15:05 +0800 Message-ID: <20230922091505.2196197-1-zhaoyang.huang@unisoc.com> X-Mailer: git-send-email 2.25.1 MIME-Version: 1.0 X-Originating-IP: [10.0.73.40] X-ClientProxiedBy: SHCAS03.spreadtrum.com (10.0.1.207) To BJMBX01.spreadtrum.com (10.0.64.7) X-MAIL: SHSQR01.spreadtrum.com 38M9FBK6033971 X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20230922_021635_261528_A480A372 X-CRM114-Status: GOOD ( 13.54 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org From: Zhaoyang Huang Double times of clear_page observed in an arm SOC(A55) when CONFIG_INIT_ON_ALLOC_DEFAULT_ON is on, which introduced by vma_alloc_zeroed_movable_folio within do_anonymous_pages. Since there is no D-cache operation within v6's clear_user_highpage, I would like to suggest to remove the redundant clear_page. struct folio *vma_alloc_zeroed_movable_folio(struct vm_area_struct *vma, unsigned long vaddr) { struct folio *folio; //first clear_page invoked by vma_alloc_folio==>alloc_page==>post_alloc_hook folio = vma_alloc_folio(GFP_HIGHUSER_MOVABLE, 0, vma, vaddr, false); if (folio) //second clear_page which is meaningless since it do nothing to D-cache in armv6 clear_user_highpage(&folio->page, vaddr); return folio; } PS: Here are all positions called clear_user_highpage which are paired with alloc_pages. IMO, it is safe to skip the second clear_page under armv6. drivers/media/v4l2-core/videobuf-dma-sg.c:441: clear_user_highpage(page, vmf->address); fs/dax.c:1612: clear_user_highpage(vmf->cow_page, vmf->address); include/linux/highmem.h:231: clear_user_highpage(&folio->page, vaddr); mm/memory.c:5974: clear_user_highpage(p, addr + i * PAGE_SIZE); mm/memory.c:5982: clear_user_highpage(page + idx, addr); mm/shmem.c:2621: clear_user_highpage(&folio->page, dst_addr); mm/khugepaged.c:796: clear_user_highpage(page, _address); Signed-off-by: Zhaoyang Huang --- arch/arm/mm/copypage-v6.c | 8 ++++++++ 1 file changed, 8 insertions(+) diff --git a/arch/arm/mm/copypage-v6.c b/arch/arm/mm/copypage-v6.c index a1a71f36d850..6f8bee1b3203 100644 --- a/arch/arm/mm/copypage-v6.c +++ b/arch/arm/mm/copypage-v6.c @@ -9,6 +9,7 @@ #include #include #include +#include #include #include @@ -45,6 +46,13 @@ static void v6_copy_user_highpage_nonaliasing(struct page *to, */ static void v6_clear_user_highpage_nonaliasing(struct page *page, unsigned long vaddr) { + /* + * This criteria only help bailing out when CONFIG_INIT_ON_ALLOC_DEFAULT_ON + * is on. The page has been memset to zero when it allocated and the + * bellowing clear_page will do it again. + */ + if (want_init_on_alloc(GFP_HIGHUSER_MOVABLE)) + return; void *kaddr = kmap_atomic(page); clear_page(kaddr); kunmap_atomic(kaddr);