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: 13395401 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 kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 749F6CD4F3B for ; Fri, 22 Sep 2023 09:16:29 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id F25406B0172; Fri, 22 Sep 2023 05:16:28 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id EAADB6B029F; Fri, 22 Sep 2023 05:16:28 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id D728F6B02A6; Fri, 22 Sep 2023 05:16:28 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0014.hostedemail.com [216.40.44.14]) by kanga.kvack.org (Postfix) with ESMTP id C586A6B0172 for ; Fri, 22 Sep 2023 05:16:28 -0400 (EDT) Received: from smtpin02.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id 9B25CB43DE for ; Fri, 22 Sep 2023 09:16:28 +0000 (UTC) X-FDA: 81263677656.02.D62860D Received: from SHSQR01.spreadtrum.com (mx1.unisoc.com [222.66.158.135]) by imf30.hostedemail.com (Postfix) with ESMTP id CDB678001F for ; Fri, 22 Sep 2023 09:16:25 +0000 (UTC) Authentication-Results: imf30.hostedemail.com; dkim=none; dmarc=none; spf=pass (imf30.hostedemail.com: domain of zhaoyang.huang@unisoc.com designates 222.66.158.135 as permitted sender) smtp.mailfrom=zhaoyang.huang@unisoc.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1695374187; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding:in-reply-to: references; bh=EtwsjmH2deAB2tkzqrv05s1FTlEyCbpyu4rOwuNpG6g=; b=mI1fzdMymSkN9CrQ6FXchqktA1Uvx6dr8XJhBFf9dHdi8Aa5IlGaCFUPJ2HjvZeRueHBZt c5mbYZ02w8BHJfNMZHL1yPiSuX3eKrg4aDWJYb5NzburkK+5g+PhC3UW8cpXmF3eIN71To DZkO1wuuN4+yFq5COrvJq+8ITok6eOs= ARC-Authentication-Results: i=1; imf30.hostedemail.com; dkim=none; dmarc=none; spf=pass (imf30.hostedemail.com: domain of zhaoyang.huang@unisoc.com designates 222.66.158.135 as permitted sender) smtp.mailfrom=zhaoyang.huang@unisoc.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1695374187; a=rsa-sha256; cv=none; b=CgtD6BiknIj7NUuhrgJQdod8pny+n6nIAPqAHSligBaRpobovwdRe467hvL6r8RJp4OcjT chzSrzZ6e8HjMKHolzZr8KWLO3Gq0rQP87r9uOLArqOHJXtyD3xbJm9jG9u0L6FdjLkDk5 NN5bgZ2wtMaMd4xOjqo3ZZorCK95/xA= 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-Rspamd-Queue-Id: CDB678001F X-Rspam-User: X-Rspamd-Server: rspam02 X-Stat-Signature: prgfofpiamiy63qpjxdgbo1wz34ybgkw X-HE-Tag: 1695374185-138502 X-HE-Meta: U2FsdGVkX1925pUumosqdQVi9ZpQKtc8omTqsRvDKtr4czlZo/IBZxUCfrDaIJ/ywmvwllMQ62YOgaTZsOzGu0GUkDD2V5t288/XPZuftotmUzx/BsJBiCguQmw1igX6ljRpg9Y1fTg/unJkjaHglI7JRW27Ezyox+6Wj2lExNU3laFCuyEW78c/UU3ZtclKiuAXw8SJDCd7H63I2hDPpDAUh3uCwf3msQDaMX3Ix+lbVck7q8EjbSms/OXpmdDtasgVVESVQIPQ7HYVp8b7h2WemBtcnm7znOkC6otwsr1vRcOoV9b23lsda9tsa/7N/BRGSMcNvSOcS62PEqJOMk53cwxJxkmLzx08LqsGaHeua66s87kevi2LkEByY4yDOyU+xB8LRULBfijFPrWBOulcoNDXFQcjpiimNiGLlJNrXqv17cypn/AsXPGJ+EZAOjuq/DnNS9nN4fcWhCyTG9XlWwYKvKsHqIPdWzEyFePVg/iF4kIjZRbn0F0wXhpLgTR+JK1gVI3b51wEq6N2Gbn4evUkM0v087lAKLvABq54EN03la7obkKVydPzvXYO9drNg86YE3e5rQsUAHfGBf2XAYOqx+cGvX7bA5kqljpLdVKIlxGoMijz9023JUrheVHP06ekG7abvSyP0FMQytAQqWjiMXbB23Xq9JDWXoHrN6qK/XDckzd+Fhj63J4UM8xhVB10QVQI2S9AzR2was9YkK4JmUgkQSBI1drXWAX85yM1EMtdC9ALXPG85VLyLZ/+t645YTM0zdV5aR6VtW0d3Um38trDhadRd/1Z2rkAMCfG9s6TlKINioMDlNrzRL5JtnbM2wM2fw4zNbxyN273nhhjz/TPa2UcooUOye0L9bPv9V+uCcLnJEEUhH1K7aQuyn26B+kCHZAPbTi/ceChfL68fybyp38HoJeWScT1fTOqZtIemwDXgwfczLpX4UWu06qKJgQUA2fJWuh c3uc9tov DDGqSQOP/IwOafIdQ9KzFtd8nn5AI9AYCaVasMr/1fXYlqQTXXipXpAU6gZLvmKqq22y1Rr7hyp7Xtepx/cksFdrW61zvX9RFT4fsguEx6CQRRLOwEFcgqvt7hs1tEG1quRZ2/oEbTc35NPotLXdBUoEIme1cCdBh5v+ml6r+V+mYGDxaKzw5mNLFCJPRajSB2INg71cuzj8To89GU5q2cO3XaoMwNpxSKvcjqrFu8aV/EGU= X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: 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);