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 B698FD2447B for ; Fri, 11 Oct 2024 06:59:38 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 4D9176B0095; Fri, 11 Oct 2024 02:59:38 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 488EB6B0096; Fri, 11 Oct 2024 02:59:38 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 302BD6B0098; Fri, 11 Oct 2024 02:59:38 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0012.hostedemail.com [216.40.44.12]) by kanga.kvack.org (Postfix) with ESMTP id 0FEDA6B0095 for ; Fri, 11 Oct 2024 02:59:38 -0400 (EDT) Received: from smtpin28.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id 47533AACB0 for ; Fri, 11 Oct 2024 06:59:29 +0000 (UTC) X-FDA: 82660420794.28.ECD10E0 Received: from mgamail.intel.com (mgamail.intel.com [198.175.65.13]) by imf22.hostedemail.com (Postfix) with ESMTP id 8AABCC000A for ; Fri, 11 Oct 2024 06:59:32 +0000 (UTC) Authentication-Results: imf22.hostedemail.com; dkim=pass header.d=intel.com header.s=Intel header.b=YgWRur4o; spf=pass (imf22.hostedemail.com: domain of ying.huang@intel.com designates 198.175.65.13 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=1728629837; 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=ZBYCBXH6XQ9jAH78nzf1SepmkA7LsUah/PbdA0qcCGY=; b=ru7EHzLkql+O6vV6JFmXS3k+w2fNHJ5Mny0mKZG8qlDndrFDEWnQFif+gF2rgUrXPIrgTy lnFjiJPv6b3j+T4HqDIOz443PlS3X2hRs08iy/3YfdsbvPhMyMf5PPRDVl6QR999cWwMoS c3mlTDoUrm7bXQkQLwqqYqmiZxQMmzc= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1728629837; a=rsa-sha256; cv=none; b=wSXeRewJ3HLZBVF3WkdRefy+Uz0W0EzDsbhHskBJwQqJVc/b/bzhTqmwyiEotfVaAJcHCF BIx8PNRZfjS0Nbxj5VZ0K815ZCmnpB2xoKkIN5Rwl0IH5M75y1jbMDwJDbhbsQboQQOVKe vLRVpB80lASclOBEChYh0CqckC9YTj8= ARC-Authentication-Results: i=1; imf22.hostedemail.com; dkim=pass header.d=intel.com header.s=Intel header.b=YgWRur4o; spf=pass (imf22.hostedemail.com: domain of ying.huang@intel.com designates 198.175.65.13 as permitted sender) smtp.mailfrom=ying.huang@intel.com; dmarc=pass (policy=none) header.from=intel.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1728629975; x=1760165975; h=from:to:cc:subject:in-reply-to:references:date: message-id:mime-version:content-transfer-encoding; bh=JdHmTcFa+nm2iysBKEaftSFgG2BVS8vi3HU9lhfDQ9E=; b=YgWRur4oa0vVq6USlFUJi9O3387rCcpk7SdFUqB7dn5qEnodYr6d2Si6 haou8OmoseKAzMXGQn2KaGOGqq3I5c8Pd0AK5ZuiEsKceJii0KtDv+/UT EumXbsbo8khO8fqUImoCjwTGVdemvg+OiVkiuZNPWRkpFRdluokuqTD/P K6Wr+HbhBMcophQ610s/WXeHvZ3aa/vctzT68mqCR++nZwlpTIqG8LD6A EVmuPvX7SIbPsHeftl20og9asdHeF6sLmgslzuWAlcZ5Pcdv7ufrqfJaY NqJRROoAuH6CUXduX8qlHOtUmcwauLhrZdvjDiWeYtN2B68oJwz/oN9Jn Q==; X-CSE-ConnectionGUID: 2IYar8H0S9qMIfZHfdrUVA== X-CSE-MsgGUID: swqrcnHNRtWkky9vkK+4rQ== X-IronPort-AV: E=McAfee;i="6700,10204,11221"; a="39149357" X-IronPort-AV: E=Sophos;i="6.11,195,1725346800"; d="scan'208";a="39149357" Received: from fmviesa001.fm.intel.com ([10.60.135.141]) by orvoesa105.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 10 Oct 2024 23:59:33 -0700 X-CSE-ConnectionGUID: 3oJ1+dsmTUuZizomQfM19g== X-CSE-MsgGUID: q69F8MBARm+VDKnd1v1Cuw== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.11,195,1725346800"; d="scan'208";a="107553921" Received: from yhuang6-desk2.sh.intel.com (HELO yhuang6-desk2.ccr.corp.intel.com) ([10.238.208.55]) by smtpauth.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 10 Oct 2024 23:59:30 -0700 From: "Huang, Ying" To: Zi Yan Cc: David Hildenbrand , Vlastimil Babka , , Alexander Potapenko , Kees Cook , Andrew Morton , "Matthew Wilcox (Oracle)" , Miaohe Lin , Kefeng Wang , John Hubbard , , Ryan Roberts Subject: Re: [RFC PATCH] mm: avoid clearing user movable page twice with init_on_alloc=1 In-Reply-To: <7C05C178-AE68-4899-BC4B-CE83C17A5BF0@nvidia.com> (Zi Yan's message of "Tue, 08 Oct 2024 09:46:28 -0400") References: <20241007182315.401167-1-ziy@nvidia.com> <9e4e3094-00a2-43bc-996f-af15c3168e3a@redhat.com> <84D24C40-AC10-4FF7-B5F6-63FADD523297@nvidia.com> <7C05C178-AE68-4899-BC4B-CE83C17A5BF0@nvidia.com> Date: Fri, 11 Oct 2024 14:55:56 +0800 Message-ID: <878quv9lhf.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-Stat-Signature: 5obpt4wgzuem6if5afbw71315ex93mqg X-Rspamd-Queue-Id: 8AABCC000A X-Rspam-User: X-Rspamd-Server: rspam08 X-HE-Tag: 1728629972-412878 X-HE-Meta: U2FsdGVkX1/03ShelHRr9t4yE1SLZNg2BHkv8wuuF4SSokGFtw6zFBYXwu1zhRzU6ra65BnECQAgfs6iiQ8GbxcJTsWoazOVFFbmKgpVDXpXbNEQTTJKS6ujwXkY+JgyHzx+Tie4fdpvCT4WaZn0EmnKQOAD/QnaQWAvDxZZw4r/HY/2SPragZ05f3DNW8Aiu3GU61dPT/n7BYNaWEXrNlpKlWzj7/+dmEZgyhuoqjuL4AlyeWznqslJtrs8QkNH2PIGtstz+oD38IvL+yFz84xR6sADRUqV/Hr5WHN+eqxw1NJ+3D1fyXZMP3eb8dN5rkWfAv5DxXnBnbd2D7P8IOlrA4Ygo7BBKr6FYYI/nSwc/DsjyPrZidCZv7gMOS/+g1IX1CTCXgDj1xaT01BW7UO6I+gOTzIN55mgDeasGtktedwC6G7b966lgONNxERQgjsXuSAYw+1jieixQwDwoKNX+Y2hDBXbvCzOo31yD3PdLeTeik3cfLaXPMuyQsLBRJeGF3iNV+FiN8PX/kbVqKHEZJHa7y6dWDF2+2ZpZUqbyktAVzopvku/SaFtXb0kJ3qKLJSFAdmywSyfm4r/sHvMcWUoOHVuu41lrPV9LQyLApBQyDTu5I+ilEQp6UjmyfOGQ+FPiAVrvzWdFPd8Qubgau+GU8DiNnJil9Yi25ejmmcwWkgF9Js8il+g48uVNElAAzztbd1Lqcg9DkgDMLgvZSLoaZfFk/cv7vLj+rSlmWJXX6EGzmXC9FACUYF213TmYopmSHutWYJ8FSfHDPfHAHpq9dm5k4hy8RCw0m6iaF816zFGGOQMOjTEp7XIDq6k9kEUy+bRuSrY6lMG4m4G2FCMdaMjo/mMXrwwNvnBaC8T9Rzwj8Q68H21KDSGR9MwyX5K40wac0ENR035gaomJ3vCejnA1Q7YijlYGb9fQiBCYNgVn/5iVZq47zbgPINtDjoxc/vOsdTbZXi GbGoqFCT 9qkkT2LtCwOR7HrzoKykzkWG3DOBMl3bFASUcrJ1/cjNMEzSRbKX2TkMDvzoLahgbL3ZseXIpy/gApGGMvID5ZX9iTaAOrQTV1G4QIRFAJk/3xHmO7WmSyJXsu5C3/BFS33pRIStCnkhX1Iqd+WqYOaY+RbHZbpOTrowhpDREB01aOCMsairPvFv0+FSAKEY4H1bX62YEMTmIvBZnK54f2xpJ79YJ/eNuAOEqNYbUkivhlJ0= 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: Zi Yan writes: > On 8 Oct 2024, at 9:06, David Hildenbrand wrote: > >> On 08.10.24 14:57, Vlastimil Babka wrote: >>> On 10/8/24 13:52, Zi Yan wrote: >>>> On 8 Oct 2024, at 4:26, David Hildenbrand wrote: >>>> >>>>> >>>>> I remember we discussed that in the past and that we do *not* want to= sprinkle these CONFIG_INIT_ON_ALLOC_DEFAULT_ON checks all over the kernel. >>>>> >>>>> Ideally, we'd use GFP_ZERO and have the buddy just do that for us? Th= ere is the slight chance that we zero-out when we're not going to use the a= llocated folio, but ... that can happen either way even with the current co= de? >>>> >>>> I agree that putting CONFIG_INIT_ON_ALLOC_DEFAULT_ON here is not ideal= , but >>> >>> Create some nice inline wrapper for the test and it will look less ugly= ? :) > > something like? > > static inline bool alloc_zeroed() > { > return static_branch_maybe(CONFIG_INIT_ON_ALLOC_DEFAULT_ON, > &init_on_alloc); > } > > > I missed another folio_zero_user() caller in alloc_anon_folio() for mTHP. > So both PMD THP and mTHP are zeroed twice for all arch. > > Adding Ryan for mTHP. > >>> >>>> folio_zero_user() uses vmf->address to improve cache performance by ch= anging >>>> subpage clearing order. See commit c79b57e462b5 ("mm: hugetlb: clear t= arget >>>> sub-page last when clearing huge page=E2=80=9D). If we use GFP_ZERO, w= e lose this >>>> optimization. To keep it, vmf->address will need to be passed to alloc= ation >>>> code. Maybe that is acceptable? >>> >>> I'd rather not change the page allocation code for this... >> >> Although I'm curious if that optimization from 2017 is still valuable :) > > Maybe Ying can give some insight on this. I guess the optimization still applies now. Although the size of the per-core(thread) last level cache increases, it's still quite common for it to be smaller than the size of THP. And the sizes of L1/L2 are significantly smaller, the likelihood for the accessed cache line to be in L1/L2/LLC increases with the optimization. -- Best Regards, Huang, Ying