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 B84C5D7494E for ; Wed, 30 Oct 2024 01:09:00 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 36B5F6B00C5; Tue, 29 Oct 2024 21:09:00 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 31B3F6B00C6; Tue, 29 Oct 2024 21:09:00 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 1BAA96B00C9; Tue, 29 Oct 2024 21:09:00 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0015.hostedemail.com [216.40.44.15]) by kanga.kvack.org (Postfix) with ESMTP id EA5446B00C5 for ; Tue, 29 Oct 2024 21:08:59 -0400 (EDT) Received: from smtpin26.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay07.hostedemail.com (Postfix) with ESMTP id 92D00160183 for ; Wed, 30 Oct 2024 01:08:58 +0000 (UTC) X-FDA: 82728483600.26.7803154 Received: from mgamail.intel.com (mgamail.intel.com [192.198.163.19]) by imf02.hostedemail.com (Postfix) with ESMTP id CE7B480008 for ; Wed, 30 Oct 2024 01:08:07 +0000 (UTC) Authentication-Results: imf02.hostedemail.com; dkim=pass header.d=intel.com header.s=Intel header.b="AQh//ERv"; spf=pass (imf02.hostedemail.com: domain of ying.huang@intel.com designates 192.198.163.19 as permitted sender) smtp.mailfrom=ying.huang@intel.com; dmarc=pass (policy=none) header.from=intel.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1730250456; 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=V8297Zwg1pwOScKEApSNVSyWqMUpOy0LhrlZDlOWi50=; b=KNtpTjHkNDRAuqEsc1quzKk/YqTf4OOPnRTP98f6m8dD33Tjqx7aFMQ0Qko/7DJsNXbuVd SVW/X4AEd0icXbfFYf7GBmsoYft4V+Kk/G7RuQG3v2RRdWadOUCbELpC9e8RKb1c2v2uWe QpmCiMNaJAiOk+5FWIoQKGiryhUlWRM= ARC-Authentication-Results: i=1; imf02.hostedemail.com; dkim=pass header.d=intel.com header.s=Intel header.b="AQh//ERv"; spf=pass (imf02.hostedemail.com: domain of ying.huang@intel.com designates 192.198.163.19 as permitted sender) smtp.mailfrom=ying.huang@intel.com; dmarc=pass (policy=none) header.from=intel.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1730250456; a=rsa-sha256; cv=none; b=4jAc55ZylCe3N5xyA5f3w0sYsZCiPUatx5vTkM9sa3ZeLTX2ZdxyHmq2c5pFHdEZcJxRqq lz0ihs643kqItl3GoeEIuGaGtGP5By7TWyZg1hyh3goHvKBa8ARbEXYp4/vBu2y9VN4x3M NAUZ2dhLgW1Php95ZOMXYJd5Z7v3I38= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1730250536; x=1761786536; h=from:to:cc:subject:in-reply-to:references:date: message-id:mime-version:content-transfer-encoding; bh=A/j5VC/aSHVFm61q0EXxwGvuMJqnDwq5sIpwU8D6jeA=; b=AQh//ERvDfExax78sS07bDAZ0Bh7LKqxvvPsZ+wnalYfUa9rk/krmzup 3D8vxVezAkr88Oyl6A7ru32fijPV7PCYoj+j6LDH9LfhaKF3KHr9DN2wI rMPJnPKEf+4ykCyukwQEZ2L0hdUSSDAoncWITfHk1IepvZJ77/uvZBIUy A+x0oMaxA4+K0/mTW9I/JllM7f22YXB1q2R4x6ulNi6MmrX4KeXqYlROb gZpmNQDdKBrQf4t88wW5ZvDMeyiKZiXIZELhBhICPHNtTPz1XqwCVNnzm DSXfXWGNso0swxhwlYE7Oxa/OgcnS5dVlrRMnvHlbeOAikjtis2FD8VBc Q==; X-CSE-ConnectionGUID: deCjF20QRneTURlYREhvqA== X-CSE-MsgGUID: r8D3uFC8SLm+LAK1gZyNNw== X-IronPort-AV: E=McAfee;i="6700,10204,11240"; a="29374908" X-IronPort-AV: E=Sophos;i="6.11,243,1725346800"; d="scan'208";a="29374908" Received: from fmviesa010.fm.intel.com ([10.60.135.150]) by fmvoesa113.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 29 Oct 2024 18:08:32 -0700 X-CSE-ConnectionGUID: B0Nv8jMIR4ilCOuwAXzqRA== X-CSE-MsgGUID: YynoMeEZQYa6O55p37JD0A== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.11,243,1725346800"; d="scan'208";a="82473620" Received: from yhuang6-desk2.sh.intel.com (HELO yhuang6-desk2.ccr.corp.intel.com) ([10.238.208.55]) by fmviesa010-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 29 Oct 2024 18:08:30 -0700 From: "Huang, Ying" To: Kefeng Wang , David Hildenbrand Cc: Andrew Morton , Matthew Wilcox , Muchun Song , linux-mm@kvack.org, Zi Yan Subject: Re: [PATCH v2 1/2] mm: use aligned address in clear_gigantic_page() In-Reply-To: (David Hildenbrand's message of "Tue, 29 Oct 2024 15:04:00 +0100") 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> Date: Wed, 30 Oct 2024 09:04:57 +0800 Message-ID: <878qu6wgcm.fsf@yhuang6-desk2.ccr.corp.intel.com> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Rspamd-Server: rspam03 X-Rspam-User: X-Rspamd-Queue-Id: CE7B480008 X-Stat-Signature: ztm3ynabxzuo7h64a4yxsncwdauarnn7 X-HE-Tag: 1730250487-876395 X-HE-Meta: U2FsdGVkX1+buWKNxwmeYF7wQvKzGBxVDzqMRYre/6qfIH+hwI/IUASSYUCWPZs2GxBNPVK/+FVp6uMOg5NgOaSLicRsbdkN9cIdhfjanBm2jf3RSefcJZyf7qDN2Zl58HtflhXSLENyxb8AMC1WmoRhXDqq1ehgBAGKq1MHPbFKQKY1vjVG5r1WbJNkgLYX0UrdUD9Ql/m4KkHjTgaxy3dybvcrTey63SBrWcpH5jsx+XGi8VoSqjwXrjyAq4umBZKaXlLAHbomIvi2M6Kmj1EZ1TShZSdsG+8+BEkzqZdwWjvkCEKKAe1e3zsspbKnReQsTplsMcJKjAGmotM6GdxEj7HAqNjF+QOWLzLSLvI+HhRWm48ArDy9llXztHaGe8Ntsf6Or1UOqhb4quIdjAvXIJa+dUYvQfUSc9SqjT44A5a5F/V+hRNJ/97Wcduf/FpXznhcnBRENZQmdlAwoN4ZwkN7AVC1sj2OidX6hkwu12UUYbbhLAWSVQZ++ScnMlXP1zXUf1KicF1wyQDTgZ7pjRGzyfAE5sF+vJNCVupYpx3/4l+8jLtUixs7NqkVq0pRGNwNeuKkLPstXrvdgqywknS8Cnr6O3oPvAvaDkKU0KwBVD1f/uRCitH7H2HsbdTgds5+OF3ykMqFzG8xcuHSGu+BokESdbxxpMSB6BGh3vPp0Dz8Pt+Y8OknvEgVRv2HrUwkb7ErXwPdgFevm5WkjkQDG9spS0hiHjQUojZGiH/MsOk77DpSrHxc2FQ0dg18wVUbTUn30j0uH1fwAy50Y079LBNapy1o9WGtOZyKw+KTFaVLdzoMIklcLCC7BanAg17uZdGbHNHcXeYskC11HxlHLMblpLmUGBRPlbm8bTpEK2e2fmXadkr1RsslTa2GgYV/lg6TxG/43Pt9ryBlqfM9nP15adETXJ0ZmsMu69f8bmIAttGE/B+SYl6Dn1VyXrO2BUD71zd3Yqh CLvqktOr WCsWYXAQ/2tnaggsCSkxakd5VfrmeDv2VibVZ8pw8Z+/Fb0oxJmXvcjrd3DZ5oHXK4achl6r3gDoGt2LDp5delwYUDwKjnxhh90exKy9ga+sApyLhn/j/yCCvnDqW1U1OY6969o99jMuMT/UQ/4+Ds5QZYPHTnked5nlXmmck63oA27ZGU4ea+lD5MPFa4fx72fBmUtTT2c76VAMRRCqSLNgPO/cbNt3yWnDqgXm7xSp/07sof8Vd9eR//dJs9BS4phvvtaSgmDk6cTtMu4C2NG5xfT4NZyaYj6vKxS00S8nYc/TnsKmOEt57/j37hBq6mo2a 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: David Hildenbrand writes: > On 29.10.24 14:04, Kefeng Wang wrote: >>>>>>>>> >>>>>>>>> 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 sma= ll >>>>> 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 correct= ly. >>> >>> 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? I don't think that it's a good idea to revert the commit without studying and root causing the issues. I can work together with you on that. If we have solid and well explained data to prove process_huge_page() isn't benefitial, we can revert the commit. > I questioned that just recently [1], and Ying assumed that it still > applies [2]. > > c79b57e462b5 ("mm: hugetlb: clear target > sub-page last when clearing huge page=E2=80=9D) documents the scenario wh= ere > this matters -- anon-w-seq which you also run below. > > If there is no performance benefit anymore, we should rip that > out. But likely we should check on multiple micro-architectures with > multiple #CPU configs that are relevant. c79b57e462b5 used a Xeon E5 > v3 2699 with 72 processes on 2 NUMA nodes, maybe your test environment > cannot replicate that? > > > [1] > https://lore.kernel.org/linux-mm/b8272cb4-aee8-45ad-8dff-353444b3fa74@red= hat.com/ > [2] > https://lore.kernel.org/linux-mm/878quv9lhf.fsf@yhuang6-desk2.ccr.corp.in= tel.com/ > >> [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) > > But these are sequential, not random. I'd have thought access + > zeroing would be sequentially either way. Did you run with random > access as well> -- Best Regards, Huang, Ying