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 21EA8D2AB3C for ; Tue, 29 Oct 2024 13:04:30 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id C1C876B009E; Tue, 29 Oct 2024 09:04:27 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id BA4EC6B009F; Tue, 29 Oct 2024 09:04:27 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 9F9A46B00A2; Tue, 29 Oct 2024 09:04:27 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0011.hostedemail.com [216.40.44.11]) by kanga.kvack.org (Postfix) with ESMTP id 7AF5A6B009E for ; Tue, 29 Oct 2024 09:04:27 -0400 (EDT) Received: from smtpin22.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay05.hostedemail.com (Postfix) with ESMTP id 37EC5412B4 for ; Tue, 29 Oct 2024 13:04:27 +0000 (UTC) X-FDA: 82726657860.22.4F77913 Received: from szxga04-in.huawei.com (szxga04-in.huawei.com [45.249.212.190]) by imf28.hostedemail.com (Postfix) with ESMTP id 84E49C001E for ; Tue, 29 Oct 2024 13:03:59 +0000 (UTC) Authentication-Results: imf28.hostedemail.com; dkim=none; dmarc=pass (policy=quarantine) header.from=huawei.com; spf=pass (imf28.hostedemail.com: domain of wangkefeng.wang@huawei.com designates 45.249.212.190 as permitted sender) smtp.mailfrom=wangkefeng.wang@huawei.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1730206948; a=rsa-sha256; cv=none; b=LCeMdgWuXwL04LQXibCQNKwt/oAZJg6IAbiAWRpn12WeK7FsRXTQ3QB9XMCs5HhzFHSWhK 4rswo4pckd9jJAZv5YomrrkeLHhedxfMiZBFlSQK4iYvaxlKDVgkFTRb6IW0gndSfKfOHs nhLhF9DSlodYoFcx6tR7HJ3RPnLkD64= ARC-Authentication-Results: i=1; imf28.hostedemail.com; dkim=none; dmarc=pass (policy=quarantine) header.from=huawei.com; spf=pass (imf28.hostedemail.com: domain of wangkefeng.wang@huawei.com designates 45.249.212.190 as permitted sender) smtp.mailfrom=wangkefeng.wang@huawei.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1730206948; 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; bh=HohHnATyyB/T+QedROmxn151/5gcbzH4DpoorYx9Wk0=; b=gHkHpscYGUMd2uB47j0oM8bOZV1iCfmT2L8SRotRJBuofwE/Ml/y65BKzsFIbd+dBxzf3L tVpwntFYeaYEP+slG6bXmb7zuCcMBKDFyOgDa2N1tlhj6bajsSCIkSeShYLF/jPMav+ncf xW2XrF23H2CKJSlV9ntPyjH7aoCwnAM= Received: from mail.maildlp.com (unknown [172.19.88.214]) by szxga04-in.huawei.com (SkyGuard) with ESMTP id 4Xd9Qx1DHVz2Df5L; Tue, 29 Oct 2024 21:02:49 +0800 (CST) Received: from dggpemf100008.china.huawei.com (unknown [7.185.36.138]) by mail.maildlp.com (Postfix) with ESMTPS id 272F71A016C; Tue, 29 Oct 2024 21:04:20 +0800 (CST) Received: from [10.174.177.243] (10.174.177.243) by dggpemf100008.china.huawei.com (7.185.36.138) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.1544.11; Tue, 29 Oct 2024 21:04:19 +0800 Message-ID: Date: Tue, 29 Oct 2024 21:04:19 +0800 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2 1/2] mm: use aligned address in clear_gigantic_page() To: David Hildenbrand , Andrew Morton CC: Matthew Wilcox , Muchun Song , "Huang, Ying" , References: <20241026054307.3896926-1-wangkefeng.wang@huawei.com> <54f5f3ee-8442-4c49-ab4e-c46e8db73576@huawei.com> <4219a788-52ad-4d80-82e6-35a64c980d50@redhat.com> <127d4a00-29cc-4b45-aa96-eea4e0adaed2@huawei.com> <9b06805b-4f4f-4b37-861f-681e3ab9d470@huawei.com> <113d3cb9-0391-48ab-9389-f2fd1773ab73@redhat.com> Content-Language: en-US From: Kefeng Wang In-Reply-To: <113d3cb9-0391-48ab-9389-f2fd1773ab73@redhat.com> Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [10.174.177.243] X-ClientProxiedBy: dggems705-chm.china.huawei.com (10.3.19.182) To dggpemf100008.china.huawei.com (7.185.36.138) X-Rspamd-Queue-Id: 84E49C001E X-Rspam-User: X-Rspamd-Server: rspam05 X-Stat-Signature: harsicck4cc9w14tcat9weqgn7j8kg6o X-HE-Tag: 1730207039-815479 X-HE-Meta: U2FsdGVkX1/Ndiqx0d6tJDlwqNKWz6NPoAZ9sIqaUYjRpT4Nf6m2TvoAMeIhHbulsF30ScnVvm2pnW5M0W5RX5CsgrAlkHNiUA6SeFs4RMLTwu5AwjEQx1YAb+L4yZOsR/aRV/F9IZiV/g/hx4Et6KhK2S8gGIMgXa/gBdXuH313HOK+Z+Ds3USDNv7C4yGX4G5LNtb8eBHH84hW7WztFs49+HDlUiH0WglTT9bf331QpwmD6bEQGv7mBKTjzi2ZYHwc10EC2W1VLToXs5ZV19M/6Bo56xJ2cE3ZbaVrCOWPhu2dd+7w7MswGCjIhijVYLQPvEO56wgLabkkO2Xr9gw28wQAABbB+bAUuszrSS01rDTuWYQapcVc+8ptqEsuf16zlPP1SE5YDMmfEaq35MZUryf+Ay749qtN5cKc2usCczpDogcFSii6MpKFY17CXuhbb5K1mhlYKKhPRWxis4DATDmWHPWFj2rAyLP3x7DsMaeyANnt5YTxdBWyF13G/Ebu4BfLuxbD95+fcXBerRCeKGy7CDUcGsrrcsxgiTIMnLsY0boa4ZIPJD0CZx5HgDPdGiH10wNh+/EjSOY/Fx45szMsFA4cpseY36MzGlIJleCDpEkauA6RzzDrxtKQdn1ZeAJ6LXH4QnKdG6o8yk172YD9coxaWVQfoIA833LF4VTThnsR3GuarpisWZjbmvmdVXqSor3VAMoe9P8DEUijeu8sknxQSDoe9vj5yC1JdRIWnCFqZG19cpiymR+WbXdkP46Dv0zkK82OiHoKE3rSTwpHb+xoBUsWXl5gN8ZUUV9y0NdJtA7gp0LOem9HMmSzAUIkk947IBqgA0tlcNRRxLBGm6/2JriWG6OspeShIrZNQIwmSmGE48vYLHhEvgHiXNoMChtD52Hu022g9IPvLElT2hBERZ3LqTIE4ePwZKm2XmisgyToNh+J4pYeQ8DgLTeT+FsrhkHi3H7 gWSswU2j ygfeuOa4e+tHjRa8aQu5VXS/VsdcFDLMVnKiOvrkBSv460CAXHCOOfmkqybnH5RgY7Jpeizrzi0ppyG+9kg/fpXaGBiXjHoiwuCKKm50yeZ/7Xm9y6Tc/aWlcMWzRqdE96IUGd7R+F7N5k3UogCRX1VxbXjKsQoLciMXNePMtp8Ih8rDnDaXIPe80Nn+51pBJJbBOR3DakFZYJoUbh9Db6Uk9pRicvepJggt0FLtZR1QQ5JYPJawdGaVxb5uwViz1mWrnkxHqpVbvoZs= 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: List-Subscribe: List-Unsubscribe: >>>>>>> >>>>>>> That should all be cleaned up ... process_huge_page() likely >>>>>>> shouldn't >>>>>> >>>>>> Yes, let's fix the bug firstly, >>>>>> >>>>>>> be even consuming "nr_pages". >>>>>> >>>>>> No sure about this part, it uses nr_pages as the end and calculate >>>>>> the >>>>>> 'base'. >>>>> >>>>> It should be using folio_nr_pages(). >>>> >>>> But process_huge_page() without an explicit folio argument, I'd like to >>>> move the aligned address calculate into the folio_zero_user and >>>> copy_user_large_folio(will rename it to folio_copy_user()) in the >>>> following cleanup patches, or do it in the fix patches? >>> >>> First, why does folio_zero_user() call process_huge_page() for *a small >>> folio*? Because we like or code to be extra complicated to understand? >>> Or am I missing something important? >> >> The folio_zero_user() used for PMD-sized THP and HugeTLB before, and >> after anon mTHP supported, it is used for order-2~order-PMD-order THP >> and HugeTLB, so it won't process a small folio if I understand correctly. > > And unfortunately neither the documentation nor the function name > expresses that :( > > I'm happy to review any patches that improve the situation here :) > Actually, could we drop the process_huge_page() totally, from my testcase[1], process_huge_page() is not better than clear/copy page from start to last, and sequential clearing/copying maybe more beneficial to the hardware prefetching, and is there a way to let lkp to test to check the performance, since the process_huge_page() was submitted by Ying, what's your opinion? [1]https://lore.kernel.org/linux-mm/2524689c-08f5-446c-8cb9-924f9db0ee3a@huawei.com/ case-anon-w-seq-mt (tried 2M PMD THP/ 64K mTHP) case-anon-w-seq-hugetlb (2M PMD HugeTLB) fallocate hugetlb 20G (2M PMD HugeTLB) fallocate tmpfs 20G (2M PMD THP)