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 098E9C6FD1F for ; Tue, 2 Apr 2024 11:18:23 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 49A5B6B0093; Tue, 2 Apr 2024 07:18:23 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 44B976B0095; Tue, 2 Apr 2024 07:18:23 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 2EAD66B0098; Tue, 2 Apr 2024 07:18:23 -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 113BA6B0093 for ; Tue, 2 Apr 2024 07:18:23 -0400 (EDT) Received: from smtpin30.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay05.hostedemail.com (Postfix) with ESMTP id 9A50740443 for ; Tue, 2 Apr 2024 11:18:22 +0000 (UTC) X-FDA: 81964343244.30.8C8EED8 Received: from smtp-out1.suse.de (smtp-out1.suse.de [195.135.223.130]) by imf11.hostedemail.com (Postfix) with ESMTP id 5C15340009 for ; Tue, 2 Apr 2024 11:18:20 +0000 (UTC) Authentication-Results: imf11.hostedemail.com; dkim=pass header.d=suse.de header.s=susede2_rsa header.b=OpjzEZSI; dkim=pass header.d=suse.de header.s=susede2_ed25519 header.b=sqEKNPI3; dmarc=pass (policy=none) header.from=suse.de; spf=pass (imf11.hostedemail.com: domain of osalvador@suse.de designates 195.135.223.130 as permitted sender) smtp.mailfrom=osalvador@suse.de ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1712056700; a=rsa-sha256; cv=none; b=DItngMAJNL6vH8X9MNcjOwY8AukOopZ6Ta91nOk428wmLIaRI/O4osPDnZ2JEf99+tAzmr Dw1KA7jVtCApNezMZ3c4yNfuGvXjjd3hoVysmB6dgzS5YOX1vackQjZ3FW22UGhmQOfvac 5Iw2zOBjvgO5imsA8SOurteSfJz6OU0= ARC-Authentication-Results: i=1; imf11.hostedemail.com; dkim=pass header.d=suse.de header.s=susede2_rsa header.b=OpjzEZSI; dkim=pass header.d=suse.de header.s=susede2_ed25519 header.b=sqEKNPI3; dmarc=pass (policy=none) header.from=suse.de; spf=pass (imf11.hostedemail.com: domain of osalvador@suse.de designates 195.135.223.130 as permitted sender) smtp.mailfrom=osalvador@suse.de ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1712056700; 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=aAq/U+6X2FU1Ny7L5MaCtJaxVAMjEFjjhoVMNVa1LRA=; b=P+jxwfustUaycn95WJvQKyI7Y+tTGHmHoTzg8yoCdg2XgQVI/z+8ZmaFE1DiOQ610Uuf0U etXEXmbpqkiVTjqkrYVpRU19bKwGJApbNuH6yNocO/FskRB7Y+2kLqDcITgyXIo8nI3Cch taF0vpcVmE639QdFl16kZw9vZ9XE/1E= Received: from imap2.dmz-prg2.suse.org (imap2.dmz-prg2.suse.org [IPv6:2a07:de40:b281:104:10:150:64:98]) (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 7E6C1345F5; Tue, 2 Apr 2024 11:18:17 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_rsa; t=1712056697; 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=aAq/U+6X2FU1Ny7L5MaCtJaxVAMjEFjjhoVMNVa1LRA=; b=OpjzEZSIeaV/xVL5HxPYCzZcziyAGhwFUlrXAJCEiamSkZp7kMngXd7IvTFJs86ubo9BwB 4/hv/kIjmcj52eCfkL8Id5Fq3NMe+Nx10EtkEpFwLBMVK9HAoBnoKWEyR2Byu3o7NF+xyP PcuH5bySzf/55VT4EwUNme6qF88H4e8= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_ed25519; t=1712056697; 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=aAq/U+6X2FU1Ny7L5MaCtJaxVAMjEFjjhoVMNVa1LRA=; b=sqEKNPI3qoHg/qxrpvEH7msdmJiNVLL2N05M4q6ZjouWy9JNY8LvXoQg5JLPeCRXk/ngnv aaoFRSl5Vn64DUCg== Received: from imap2.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 imap2.dmz-prg2.suse.org (Postfix) with ESMTPS id 0875813357; Tue, 2 Apr 2024 11:18:16 +0000 (UTC) Received: from dovecot-director2.suse.de ([2a07:de40:b281:106:10:150:64:167]) by imap2.dmz-prg2.suse.org with ESMTPSA id CgP9OnjpC2YJJwAAn2gu4w (envelope-from ); Tue, 02 Apr 2024 11:18:16 +0000 Date: Tue, 2 Apr 2024 13:19:42 +0200 From: Oscar Salvador To: Vlastimil Babka Cc: Andrew Morton , linux-kernel@vger.kernel.org, linux-mm@kvack.org, Michal Hocko , Marco Elver , Andrey Konovalov , Alexander Potapenko Subject: Re: [PATCH v3 1/3] mm,page_owner: Update metada for tail pages Message-ID: References: <20240326063036.6242-1-osalvador@suse.de> <20240326063036.6242-2-osalvador@suse.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspamd-Action: no action X-Rspam-User: X-Rspamd-Server: rspam06 X-Rspamd-Queue-Id: 5C15340009 X-Stat-Signature: zqcj58c9oorj8eup9pzft9fnqkyugzab X-HE-Tag: 1712056700-399241 X-HE-Meta: U2FsdGVkX1+aPxmKP/yFmEiGr6hTdZhImNwaY0jsSFj85OKUNC1TNPqRlPCmK0gA1jEiZdJUb3bm6AmDmeoR6OxWqCZYNQPo71PfYNfhx3lePdmEHVLkDY5Bimi+jxoy9ik8oS6pcKTfdaH0TYxwgWGE/Iivd7d+/3TbENS4rHt1dW++sxq11viyMcAf0d0qLKy/8BBB8w92I37cv11DGu6S+a8nsO/E0KPNWPCo1PgGiDBT2UDneEYbf63HRvQvbujFDqNwnoxq2VMhSCloudx27KUqiRBhPN930lnBdSbDwAEDOd5ZdN7aQkf4hZwA223zH2kaVreUvTGCFLRT1uLt5BhbPSKKjzRZiOo/KaXDZyEJ/tM7RtOE15bcIfNu0mis4o7jNN3YVF2bfd6XmUe+37Io1tX9t/D5y36+vM2ImdpJgH0aFNsgtPQgSc1OfWtscAf0jdJwHo4JGteHgcWheVCZp9ynY43LJ7j9FGnenAZ0nYsAvNwqmoXz5TtZBoOMdrsqPnC5qs7aErLTWtLjfC4qTseuY/gsileI0aXL/MbjaMYse2n07648w/Bwjcg9GtggYEm+wZum6Ko0rgPDgo9I0UGMMx1++tJ29T5Q77RwlKPXQcIkGn3LYIquq8Ekn1za0J7TkPADPZJ3smvVwWd5VGF/OBGblNK0lMrJNu7fqSGtf1Y7BoV8JIkIGuDFNP6xuRY73zQYKHePyZ6cnkw+nJ0ezacqRuaWhJXantyR9kdDoi0pp05bnPi64aLd+sm6rKswbBpQyU34trh7D58c1LQiulTDKiYSvrLyzC7SBp8j5XaRlA5vZIFMkycmzcMziCdfOGEXm69/bAr7+efaMLCdIhdd3WakHoB1HZXOZCG4uZjyeX039Rll/NRs05u6rGQpRkPbeXW1B3HY7gt1DkIJVo/o4UWGygc/Kb5yxpXVlRwKiQ1+k/juffsIAkrATCBxrOYGuNN Sw57msOS S6wp7nLtbhhdE4ZAAo99Z5p3Ka3ShHPLccgYDQmMK4X78XO31e4ExjfB/ZNcks4FGh/08/BTGdHaRcEYzml6aJKxgmFpt43AHBM02pE7E58f+A2oQhcPxUjfOXzThwEfkExedQuba3Il9SuQvydN6JQ4XZ3xf8SOVY9opuArxwCHuhJFxm7+hWQNh7MiiDWXKRjUBfZqCTzQBwBYoc/jgKXp5CIh8DIeCNcC/KUNYvPVDH9kNx2+CmBTe3PBwTtY45r09 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: On Tue, Apr 02, 2024 at 12:13:37PM +0200, Vlastimil Babka wrote: > Subject: metada -> metadata Ooops. > > Signed-off-by: Oscar Salvador > > Reviewed-by: Vlastimil Babka Thanks! > > @@ -355,31 +375,21 @@ void __folio_copy_owner(struct folio *newfolio, struct folio *old) > > - * We don't clear the bit on the old folio as it's going to be freed > > - * after migration. Until then, the info can be useful in case of > > - * a bug, and the overall stats will be off a bit only temporarily. > > - * Also, migrate_misplaced_transhuge_page() can still fail the > > - * migration and then we want the old folio to retain the info. But > > - * in that case we also don't need to explicitly clear the info from > > - * the new page, which will be freed. > > + * Do not proactively clear PAGE_EXT_OWNER{_ALLOCATED} bits as the folio > > + * will be freed after migration. Keep them until then as they may be > > + * useful. > > */ > > The full old comment made sense, the new one sounds like it's talking about > the old folio ("will be freed after migration") but we're modifying the new > folio here. IIUC it means the case of migration failing and then the new > folio MIGHT be freed. So I think you made the comment too much concise to be > immediately clear? It probably could be improved by saying that there is no need to clear the bit from the old folio since that will be done when __reset_page_owner() gets called on the old folio. Now, answering your question about whether we can fail or not at this stage. I looked into this a few weeks ago and I made my mind that no, we cannot fail at this stage, and the following is my reasoning. This is the callchain that leads to folio_copy_owner: migrate_folio_move move_to_new_folio migrate_folio migrate_folio_extra folio_migrate_copy folio_copy folio_migrate_flags folio_copy_owner folio_copy_owner() gets called only from folio_migrate_flags(). And all the functions that call folio_migrate_flags(), return MIGRATEPAGE_SUCCESS right after calling it, so it is kinda the last step of the migration. So no, we cannot fail at this stage, so we do not have to worry about undoing this. -- Oscar Salvador SUSE Labs