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 12258C02180 for ; Thu, 16 Jan 2025 10:15:16 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 7B09F6B007B; Thu, 16 Jan 2025 05:15:16 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 75EB66B0082; Thu, 16 Jan 2025 05:15:16 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 5FF3D6B0085; Thu, 16 Jan 2025 05:15:16 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0013.hostedemail.com [216.40.44.13]) by kanga.kvack.org (Postfix) with ESMTP id 457C26B007B for ; Thu, 16 Jan 2025 05:15:16 -0500 (EST) Received: from smtpin30.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id DA4E4C09E0 for ; Thu, 16 Jan 2025 10:15:15 +0000 (UTC) X-FDA: 83012907390.30.929AC1D Received: from smtp-out1.suse.de (smtp-out1.suse.de [195.135.223.130]) by imf24.hostedemail.com (Postfix) with ESMTP id A540718000E for ; Thu, 16 Jan 2025 10:15:13 +0000 (UTC) Authentication-Results: imf24.hostedemail.com; dkim=pass header.d=suse.de header.s=susede2_rsa header.b=QOPS2zL0; dkim=pass header.d=suse.de header.s=susede2_ed25519 header.b="/Vcf34mZ"; dkim=pass header.d=suse.de header.s=susede2_rsa header.b=QOPS2zL0; dkim=pass header.d=suse.de header.s=susede2_ed25519 header.b="/Vcf34mZ"; spf=pass (imf24.hostedemail.com: domain of osalvador@suse.de designates 195.135.223.130 as permitted sender) smtp.mailfrom=osalvador@suse.de; dmarc=pass (policy=none) header.from=suse.de ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1737022514; 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: in-reply-to:in-reply-to:references:references:dkim-signature; bh=TeOMKud/SXWoYbl0R/JajHQBQIzTmEiDuk5NKJolk4s=; b=T4GIlgnoebp9Pfh3BPLovS5bRllbfKwlMr12UQQMPPQCjLL5li1DxzZ+mEJSE+2co3emgK 61C46JIywrxx8B4M2QYrjgezYPd75aEE5oI6Bg1OMltBDcxAmfyRH7LnksSg6tFBNKaq56 HVdRvcCAvYd3Eai4RhKJO9rdsK3ffaM= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1737022514; a=rsa-sha256; cv=none; b=uOAAZiMmyzkUYs2ZL4rzJwdiVl0DEg9gMmrk33Hzkx+hg4nG668t5q1DrvP9trUjMk68PH xe792XmXLwZJcCMXaEDwqd8DmR44fPdCptQ7wveNed3ZYnZ6nKixJ8nbdhqkFHfU4OQ76Y 3HSE0WQFJa91ywC+i0ZY6Ycc/6LYX6U= ARC-Authentication-Results: i=1; imf24.hostedemail.com; dkim=pass header.d=suse.de header.s=susede2_rsa header.b=QOPS2zL0; dkim=pass header.d=suse.de header.s=susede2_ed25519 header.b="/Vcf34mZ"; dkim=pass header.d=suse.de header.s=susede2_rsa header.b=QOPS2zL0; dkim=pass header.d=suse.de header.s=susede2_ed25519 header.b="/Vcf34mZ"; spf=pass (imf24.hostedemail.com: domain of osalvador@suse.de designates 195.135.223.130 as permitted sender) smtp.mailfrom=osalvador@suse.de; dmarc=pass (policy=none) header.from=suse.de Received: from imap1.dmz-prg2.suse.org (imap1.dmz-prg2.suse.org [IPv6:2a07:de40:b281:104:10:150:64:97]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by smtp-out1.suse.de (Postfix) with ESMTPS id 0F443211C4; Thu, 16 Jan 2025 10:15:12 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_rsa; t=1737022512; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=TeOMKud/SXWoYbl0R/JajHQBQIzTmEiDuk5NKJolk4s=; b=QOPS2zL0S+bWQ6T1MadnsKG8wW4Q/FHnlXa5A8oq2LVViCwvqKo4PzCCCqAEYmQmNCpx0G 5LfrAnBvmuv2cVS+jHI+aQErwoLJzAAd1d7rEcC5XaNKecIu7w7vR0p+09HCjTo4NUTwLJ plbiWtSilvIqkc7eI8pUe8L6Lxvng+Y= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_ed25519; t=1737022512; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=TeOMKud/SXWoYbl0R/JajHQBQIzTmEiDuk5NKJolk4s=; b=/Vcf34mZIjuIxNzy4DbGWM6NmTzzp1/9L+QRTAZAWHCOP724OHkm0cAYQcKUQstjBlHS8I uJeRJKhF+fRMx/AQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_rsa; t=1737022512; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=TeOMKud/SXWoYbl0R/JajHQBQIzTmEiDuk5NKJolk4s=; b=QOPS2zL0S+bWQ6T1MadnsKG8wW4Q/FHnlXa5A8oq2LVViCwvqKo4PzCCCqAEYmQmNCpx0G 5LfrAnBvmuv2cVS+jHI+aQErwoLJzAAd1d7rEcC5XaNKecIu7w7vR0p+09HCjTo4NUTwLJ plbiWtSilvIqkc7eI8pUe8L6Lxvng+Y= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_ed25519; t=1737022512; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=TeOMKud/SXWoYbl0R/JajHQBQIzTmEiDuk5NKJolk4s=; b=/Vcf34mZIjuIxNzy4DbGWM6NmTzzp1/9L+QRTAZAWHCOP724OHkm0cAYQcKUQstjBlHS8I uJeRJKhF+fRMx/AQ== Received: from imap1.dmz-prg2.suse.org (localhost [127.0.0.1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by imap1.dmz-prg2.suse.org (Postfix) with ESMTPS id 669F213A57; Thu, 16 Jan 2025 10:15:11 +0000 (UTC) Received: from dovecot-director2.suse.de ([2a07:de40:b281:106:10:150:64:167]) by imap1.dmz-prg2.suse.org with ESMTPSA id L88iFC/ciGdBRgAAD6G6ig (envelope-from ); Thu, 16 Jan 2025 10:15:11 +0000 Date: Thu, 16 Jan 2025 11:15:09 +0100 From: Oscar Salvador To: Peter Xu Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org, Breno Leitao , Rik van Riel , Muchun Song , Naoya Horiguchi , Roman Gushchin , Ackerley Tng , Andrew Morton Subject: Re: [PATCH v2 3/7] mm/hugetlb: Rename avoid_reserve to cow_from_owner Message-ID: References: <20250107204002.2683356-1-peterx@redhat.com> <20250107204002.2683356-4-peterx@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspamd-Action: no action X-Rspamd-Queue-Id: A540718000E X-Stat-Signature: cuxfi1r9y78gsb44dit8p5qxk7osyz4e X-Rspam-User: X-Rspamd-Server: rspam12 X-HE-Tag: 1737022513-582973 X-HE-Meta: U2FsdGVkX19rDDTqDZVSOMeKoc2wlKsST+mQKdC28XoISfMHGZOBvSrBsLnIBc1WXcBKai2OJMDT0AEeCP/zkVB+0egRBSo94uK4H0csbasJjc2yhnhcQJ1mChhUj01S3xyllz+MSM/kqPltxt7UPllPY5LQfwSw3ZKkpQ6Gjf0VbJrK0/RY4EhrwT9KhxqUxcJP/iE9pwn/8/yZxOk+fT494x8SPMqwgpxWpor+cL9QZodDPKcajQBYGsnK0VXChjazC2QcefDc80iJ/WMEH39Wsu2eLTFKnEAXxGkrrLBhV9CeTLBteU/NNgqo7ryUpHbkcLE1peS7CCSv9jGXqktZOsRjLob7FaoNFXO1icyZ8nt7pqEL1nHG7DxECK5i3oy2weN7xIBm0nhQ4OKDPCuWdQsfLWPl+XVePJ/f5f6MA9d0DgDP9bQbDZfTcdxdDOuH6g0joVUvtFBLIMrkabaX7f/KVWVkWGOvdLzu5YdKwtfj1hjLcba3K786ZhuRkb74J2j9TQAH+frKEbTpvG/c4RiCgAaeig7uijZpnO29+IWPs2+ouOfdbcVQB+ucroeBu7wAViBmx7J6XYEGF04EB1Z1ripTpproSi4Dw958uCQ5149tY3GlNzdtjXP9yDhJ9lV7wFkpP3T3gVKZMRw+jJ91CmoWyM7JlI8zwEHhhAovbuCM74anulgYD4PW+JgKYKJTM0GzFOmL/fVEXjT+RWFybND8D8mteP25RZM8J5/RaNVN3FvgmrD/MyrGbzs9gmOeYOdRYDMejcgw4j+PSDeUSWp4XVOjS/ufvPu8nJUHmO11aw+GOoUHXy7MqtpEhXhBlFyHTNbX+jV1zV5nzJM7uJbJqJRgMXIMWKGp0XBFw+Ze2QSzmP4gsK/Y6VBLiJJiPdGr3U7dDJ+77h2+mtDokpA+kzFsKoh/v2ihgD3i92Mrk/jCcbMoqtJP82W1JpWUgLzVKPH5md+ NEPLSgpO c7CJ1Cv7bqND8eZQzpoM3bUHvcx2LZWAY00qPgkL7G6TbzniyQ06mkVFIzFj6wV6SNOvqd6Xdhm4w/dgG2BIoyXW0e6ODHzjCts3/UUdCW17gFCUxuKFPDkl4DE7vpxb9hVeuluZtAMLbwWIy8EkmQYM05oS608jh5IzxPMej0GpXe+sCILN/AP6v87tYg/8z9dACgccze7xWzMXp5hEx3IquT3carcGBWxqMP5VfpC7wSZcnlkrc2f4AnyX4YeU8OU01zGkAEOLF9HDW1uFiCOfj30i9EWN/laAgycHJuzSun0pKSw1GfEvrDYMBjKymXtpbrBJ7p4kulxjzjEc+psKlU1aSlzNc6ZFi0qlUUHOqqu6tryaGZRRPbT7hIZyykK8xp9D/Q2d5G7K1OiWWT7cNYw== X-Bogosity: Ham, tests=bogofilter, spamicity=0.001028, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: List-Subscribe: List-Unsubscribe: On Mon, Jan 13, 2025 at 11:19:27AM -0500, Peter Xu wrote: > Oscar, > > On Mon, Jan 13, 2025 at 12:20:34PM +0100, Oscar Salvador wrote: > > On Tue, Jan 07, 2025 at 03:39:58PM -0500, Peter Xu wrote: > > > The old name "avoid_reserve" can be too generic and can be used wrongly in > > > the new call sites that want to allocate a hugetlb folio. > > > > > > It's confusing on two things: (1) whether one can opt-in to avoid global > > > reservation, and (2) whether it should take more than one count. > > > > > > In reality, this flag is only used in an extremely hacky path, in an > > > extremely hacky way in hugetlb CoW path only, and always use with 1 saying > > > "skip global reservation". Rename the flag to avoid future abuse of this > > > flag, making it a boolean so as to reflect its true representation that > > > it's not a counter. To make it even harder to abuse, add a comment above > > > the function to explain it. > > > > > > Signed-off-by: Peter Xu > > > > I agree that the current name is quite misleading, and this patch > > improves the situation substantially. > > The only thing I am missing here is that the comment you added could be > > more explanatory as to why new call sites do not want to make use of the > > flag. > > > > IIRC, not using so, will bypass all vma level reservations as you > > s/not using/using/? Only using the flag (setting to true) will bypass vma, > but I could have misunderstood this line.. Yes, sorry. > > mentioned, which means that the child can get killed if the parent > > makes use of the page, as it is the parent the only one that made a > > reservation. > > The paragraph I added on top of alloc_hugetlb_folio() is trying to suggest > nobody should set this to true in any new paths. Yes, you are right. I thought we could be more categoric, but curent comment seems fine. > So far, the reservation path should have nothing relevant to stealing page > on its own (if that is what you meant above..) - page stealing in hugetlb > private is done separately within the unmap_ref_private() helper. Here the > parent needs to bypass vma reservation because it must have consumed it > with the folio installed in the pgtable (which is write-protected). That > may or may not be relevant to page stealing, e.g. if global pool still has > free page it doesn't need to affect child from using its hugetlb pages. No, I kind of misinterpreted this. Now, let me see if I get this straight: 1) parent maps a hugetlb page, but not yet fault in. 2) forks, child faults-in the page 3) child doesn't have any reservation, when 'cow_from_owner' set to true we check whether we have a spare hugetlb page to satisfy that 4) parent faults in the page 5) we do not have spare hugetlb pages, so we 'steal' it from the child with unmap_ref_private. Is my understanding correct? -- Oscar Salvador SUSE Labs