From mboxrd@z Thu Jan 1 00:00:00 1970 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 3354BEE3F3F for ; Wed, 13 Sep 2023 01:13:31 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 3F8036B0151; Tue, 12 Sep 2023 21:13:30 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 3A84D6B0155; Tue, 12 Sep 2023 21:13:30 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 26FED6B0159; Tue, 12 Sep 2023 21:13:30 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0016.hostedemail.com [216.40.44.16]) by kanga.kvack.org (Postfix) with ESMTP id 186496B0151 for ; Tue, 12 Sep 2023 21:13:30 -0400 (EDT) Received: from smtpin18.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay07.hostedemail.com (Postfix) with ESMTP id E395F160D90 for ; Wed, 13 Sep 2023 01:13:29 +0000 (UTC) X-FDA: 81229801338.18.5B2CEAB Received: from mail-lj1-f179.google.com (mail-lj1-f179.google.com [209.85.208.179]) by imf26.hostedemail.com (Postfix) with ESMTP id 14D0D140014 for ; Wed, 13 Sep 2023 01:13:27 +0000 (UTC) Authentication-Results: imf26.hostedemail.com; dkim=pass header.d=gmail.com header.s=20221208 header.b=YpEUDILZ; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf26.hostedemail.com: domain of huangzhaoyang@gmail.com designates 209.85.208.179 as permitted sender) smtp.mailfrom=huangzhaoyang@gmail.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1694567608; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=Fjsc0hUdTRQvDzUtDcM0eOVV6oXOZ8WCpdv+IWRoLPY=; b=LHnEcHh7NO+QNpoSAPl1TgJOIDpzvY0uJYJLQqurU7m0rtguKO+nJc96BJLug9ad3F3PAW mGdPvefjnWQIhnfydPUs8R+W+ZohKbbz5Nun/kw1XPHIZbr80z6nGVoRpCF1pEYb6uxB/J yyEOHSBEIBAZvnyQZUwnbtT1QByWyfY= ARC-Authentication-Results: i=1; imf26.hostedemail.com; dkim=pass header.d=gmail.com header.s=20221208 header.b=YpEUDILZ; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf26.hostedemail.com: domain of huangzhaoyang@gmail.com designates 209.85.208.179 as permitted sender) smtp.mailfrom=huangzhaoyang@gmail.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1694567608; a=rsa-sha256; cv=none; b=f2mZB13oOJ/dzJBy5Y4+gvjJXRqv7pnPR4+N4Kp2/1ZYp4dCK0ZMxgTcQzmnj+Qxt+6lKW TT8A+5n26WttDgqKvc+1GxOPLZMbZJe/nBJShDc/Oa/ddOp/com8z3PrmHz++2gQhfPQB8 nIRAtDNkG84v6BzpBUfVUUT42dYs/m8= Received: by mail-lj1-f179.google.com with SMTP id 38308e7fff4ca-2bf78950354so62630131fa.1 for ; Tue, 12 Sep 2023 18:13:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1694567606; x=1695172406; darn=kvack.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=Fjsc0hUdTRQvDzUtDcM0eOVV6oXOZ8WCpdv+IWRoLPY=; b=YpEUDILZyvqALlZJ3vzeUUl6KcFzRz0jBjbDiyWFu/HDfkyFy2xoEc8yEbvEEl4r2u JihrKOJ+Ei0OLrJ04NSqq6YhW+UFCkjp+JRHnKpRT7N+4eCJMqw+6eB2A4pY2Svs3qqa Wgk5ygeMrfHkW/hXG1rCfbg6/gMAVWemINXWMkzKPQlJoxrH/1bn/phDuYQ5NkrDCHGc HZd9fqVZQ0JMXbEXLHtGiOSgu5ox0N/0LHOpQYsXicI5khoBI9v08xrr72iYKiqNwm5s 840M0xlWlwCvuolSPBNJp/qmVoF2Kk2EtRy4BnM9Jy9ulSitbZIEa8WzWvTlaz5g/Gdj Pr2Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1694567606; x=1695172406; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=Fjsc0hUdTRQvDzUtDcM0eOVV6oXOZ8WCpdv+IWRoLPY=; b=lMWUjFuR9axum9MZOogUyWX/EqNSBMJRV/bWFYHOFuZ6cchK08TF7oexjT70b7IkrA T6vCltsBK+qL8gB5uIrUe98hVVsREk94jW7HhZpDd7z5lZWb4RBF5QE7MRzulYPVwVQ8 hOB5wAVDhu65FboxcTjYKJozTHDPpCtOy4fhYzfSQHxmsduomGn2MUxhRUGrhibBrqWt 5VhYpRlPnuLR4SP2ze6I5Plmmub/WVsIDsHZzLPu1PAlaVTJeg0lSAKx3KoAbkm3mEkp wCr/9yoZH/14L+caDpqivcfZhCHxDDQCUU7x6JuOqUxiVe/3zmS8vP8QTIGmgQWE2Fso XxoQ== X-Gm-Message-State: AOJu0YxmPJKftska7LMRIIg8FlmegcZyQi2C036MGgme9t8cIMs1VkRe aCrrMRvl2XJzXhL/+NCw5SPYlLnUpC09cELp1aykuN4fznw= X-Google-Smtp-Source: AGHT+IFdSC8jWmSSvotWYWDGkhIhZ5CzInhYHDzGHWbKW3OweLNGZvJfOCLK2Yf+3MpotTkkbuQ+zFWHdi6GGBmfpD4= X-Received: by 2002:a2e:8386:0:b0:2bc:e3a5:57aa with SMTP id x6-20020a2e8386000000b002bce3a557aamr1020414ljg.0.1694567605937; Tue, 12 Sep 2023 18:13:25 -0700 (PDT) MIME-Version: 1.0 References: <20230912103334.2074140-1-zhaoyang.huang@unisoc.com> In-Reply-To: From: Zhaoyang Huang Date: Wed, 13 Sep 2023 09:13:14 +0800 Message-ID: Subject: Re: [PATCH] arch: arm: remove redundant clear_page when CONFIG_INIT_ON_ALLOC_DEFAULT_ON is on To: Matthew Wilcox Cc: "zhaoyang.huang" , Russell King , Andrew Morton , Mike Rapoport , linux-mm@kvack.org, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, ke.wang@unisoc.com Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: 14D0D140014 X-Rspam-User: X-Rspamd-Server: rspam04 X-Stat-Signature: xzxqsxo5fbh8ey8txzesa48uh1a7hp1i X-HE-Tag: 1694567607-723115 X-HE-Meta: U2FsdGVkX19mCikDTbvJg0ChPsUdcRO9sD5YbfneSwuY60PEc8MGAF6THFFao5T3gKuhpD6vGtXuR/6rKM3aduWnkst+kUOqJefOMrz9Q3YnjAhI5xJVDbxQ2PTE/OY2Q6Ge7X2rne8eEFV/4UiWAu3aD9gqr1YiDdWd9H0qW8nbylcgGQGsQSANogOpgJlEOipvxwULx9qeenOJbY3c/YmcBkMJgX+vGKMWM3t7nNaS80/Legw8le162Eg1crQipcYtrrKOyenlE9bLMW9iHGufSXtrjPqkxYxHPz8B27RkWzBucPEjTSSBJjd9KGA2hdLvjj0KTG0nxS9KuqEYeEKSj8E+svtKz7EIqnCuF4IPZUl2nX1d3l9EiXBst5nYOmdOWLrM0ixyjURd9vbzum20J99t/vDd7BuOCZA7IRIjJmbCcJTHzuH+j0u2sWob9iJjPvJZv5pHSS9QkCj0ybSq5MrEEhOL1prMWExiVBv0YMcV7X2T6bUtbeDGk9xZAWnbzRpDQ1DswecmL5jxzIUZZoZwAvpwNxkMLhxnKrRkYQu7WdjgIywjlpiEN/8y4Ytxy1HR7UmpnF8mF3GzOOnNE8HXXfJ8mVTglIclrYYaftWbcdGMImcHDXx4GpYlAcfPTk0lBO0FDXO05LPjKO5RJXQKC34npeFBdxoDJaORoXE2gcY8DFcCkutDekfx8tRRNfRavYwmeH7qI/cdTth85RGq4OFOnI4xIbLuiL8+JOEU9OjMyUnCYiZj6voMYfDtQBgxz0GeGMDhOgMDyk8F7tjj7CE6ereVHPkbrqxDI2z7skCcDHKTad/tcLlF++BOIgHXjK2NReYLQ5HglqidP8Iy53DtEUj9Sl2Uai0dfnXd0qF0uThGLLWg/n4bvHsphSI37cIY+3lDFvCB9D3rP3jCpr+kbCDos9mtg1tMWIPS43y36Nn5WOp8FVkRUrhz0VIFlO8A/yVa+ot e6rKlCMg kgHkNa6JqThk5vW6s/ji+GFb5ZC1SsorUUJlBO6DQw2j4yh8nlYFcQa5L/1/ESCJuw4v/RXCMKMqmgiHsDTRvYp3qigw4A0yrK0jRZ18Z8qfGh03QKiTnOHAra5uNoCx1aDEai57TzagoDkEFO9zLvQVFFnQ5qMfDWjQrinxRkm5TZE8BjHBDZZL4vvTVaaMcl5k9eLuBwUKGHd2kUAtc+nqDjSgriwPC5foHtdX02oSJk9OOtfiHW6z0JGbfhcxZYlTRH71mqeIyKm9qO7qKV50aw4KJMw4rYKEb0rVf6LgJHGs35b7Zwmz0vofuNGmX3ExOPTQIssZkT8xm9WksPmqePzu7e6Xxsfx3Yz1f+4mi45VPhwtA757OsfCkJFwjIyRjwUtDmEZbwJvqOOlOdSpioKJKFUrCw88Wmg+kN/Qirbk7rRj6OjFeWZmJKGrdZuCpvxBD3bdDe/fuogQ36FPrr1u39XN4sI9m4O5kNxo4l3kYNekQd4g0EmSzZJyu3sQ/Fc6URaGwvro= 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: On Tue, Sep 12, 2023 at 8:18=E2=80=AFPM Matthew Wilcox wrote: > > On Tue, Sep 12, 2023 at 06:33:34PM +0800, zhaoyang.huang wrote: > > 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=3D=3D>alloc_page=3D=3D>po= st_alloc_hook > > folio =3D vma_alloc_folio(GFP_HIGHUSER_MOVABLE, 0, vma, vaddr, fa= lse); > > if (folio) > > //second clear_page which is meaningless since it do nothing to D-cache= in armv6 > > clear_user_highpage(&folio->page, vaddr); > > This is, of course, not the only place which calls clear_user_highpage(). > Please explain why this patch is safe for all the _other_ places which > call clear_user_highpage(). 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); > > > return folio; > > } > > > > 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, unsi= gned 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 =3D kmap_atomic(page); > > clear_page(kaddr); > > kunmap_atomic(kaddr); > > -- > > 2.25.1 > >