From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp-out1.suse.de (smtp-out1.suse.de [195.135.223.130]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 25BE326AF6 for ; Thu, 16 Jan 2025 10:15:13 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=195.135.223.130 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1737022516; cv=none; b=UKPHnbMGfjyhQBzM5P5+9nBrET75wFAjWdJi+m22pU8fd5syurYOlSg9ED90mokNuCjpwrLTKabLUpd4UX58842G6o8PInRd8tSZUBKaKWHmuhz0x3p+wce9/0a5ggW9t2On9X9tdD9196FdtZVPE1HnKjGQKAf1gFpbRVQfSHc= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1737022516; c=relaxed/simple; bh=hHyu9lZ5Xsax+8Xe18zVJ01WwEsCKDqSwvla7ijNdcg=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=Y4UqT2JE2L/r2Tq1nNYhvVRq0qUCzjdEB4qW6Nc9JNdgRI8a/07awABCUpUt+rjoLWiV3n/nW2mSfYLQ4odq7kRD/xuuIdGGvcJ3XnWSiJgH+W+E94m9C7rU++rOQsfs41e+Cf3rQKI5doNnZ70dPPGGArf6WRYLhVrD2Td9EM8= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=suse.de; spf=pass smtp.mailfrom=suse.de; dkim=pass (1024-bit key) header.d=suse.de header.i=@suse.de header.b=QOPS2zL0; dkim=permerror (0-bit key) header.d=suse.de header.i=@suse.de header.b=/Vcf34mZ; dkim=pass (1024-bit key) header.d=suse.de header.i=@suse.de header.b=QOPS2zL0; dkim=permerror (0-bit key) header.d=suse.de header.i=@suse.de header.b=/Vcf34mZ; arc=none smtp.client-ip=195.135.223.130 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=suse.de Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=suse.de Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=suse.de header.i=@suse.de header.b="QOPS2zL0"; dkim=permerror (0-bit key) header.d=suse.de header.i=@suse.de header.b="/Vcf34mZ"; dkim=pass (1024-bit key) header.d=suse.de header.i=@suse.de header.b="QOPS2zL0"; dkim=permerror (0-bit key) header.d=suse.de header.i=@suse.de header.b="/Vcf34mZ" 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== Authentication-Results: smtp-out1.suse.de; 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-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> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspamd-Queue-Id: 0F443211C4 X-Spam-Level: X-Spamd-Result: default: False [-3.01 / 50.00]; BAYES_HAM(-3.00)[100.00%]; SUSPICIOUS_RECIPS(1.50)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.20)[-1.000]; R_DKIM_ALLOW(-0.20)[suse.de:s=susede2_rsa,suse.de:s=susede2_ed25519]; MIME_GOOD(-0.10)[text/plain]; MX_GOOD(-0.01)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; DKIM_SIGNED(0.00)[suse.de:s=susede2_rsa,suse.de:s=susede2_ed25519]; FUZZY_BLOCKED(0.00)[rspamd.com]; ARC_NA(0.00)[]; RBL_SPAMHAUS_BLOCKED_OPENRESOLVER(0.00)[2a07:de40:b281:104:10:150:64:97:from]; TO_DN_SOME(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVRCPT(0.00)[gmail.com]; RCVD_TLS_ALL(0.00)[]; SPAMHAUS_XBL(0.00)[2a07:de40:b281:104:10:150:64:97:from]; RCVD_COUNT_TWO(0.00)[2]; RCPT_COUNT_SEVEN(0.00)[10]; FROM_EQ_ENVFROM(0.00)[]; FROM_HAS_DN(0.00)[]; FREEMAIL_CC(0.00)[kvack.org,vger.kernel.org,debian.org,surriel.com,linux.dev,gmail.com,google.com,linux-foundation.org]; RECEIVED_SPAMHAUS_BLOCKED_OPENRESOLVER(0.00)[2a07:de40:b281:106:10:150:64:167:received]; RCVD_VIA_SMTP_AUTH(0.00)[]; TAGGED_RCPT(0.00)[]; DKIM_TRACE(0.00)[suse.de:+]; MISSING_XM_UA(0.00)[]; DBL_BLOCKED_OPENRESOLVER(0.00)[suse.de:dkim,imap1.dmz-prg2.suse.org:helo,imap1.dmz-prg2.suse.org:rdns] X-Rspamd-Server: rspamd2.dmz-prg2.suse.org X-Rspamd-Action: no action X-Spam-Score: -3.01 X-Spam-Flag: NO 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