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 213B9C54E58 for ; Thu, 21 Mar 2024 11:52:52 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id A1C156B0085; Thu, 21 Mar 2024 07:52:51 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 9CC7C6B009B; Thu, 21 Mar 2024 07:52:51 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 893FE6B009C; Thu, 21 Mar 2024 07:52:51 -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 7AB436B0085 for ; Thu, 21 Mar 2024 07:52:51 -0400 (EDT) Received: from smtpin22.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id EC0E9A1E8A for ; Thu, 21 Mar 2024 11:52:50 +0000 (UTC) X-FDA: 81920884500.22.3E5AB06 Received: from smtp-out1.suse.de (smtp-out1.suse.de [195.135.223.130]) by imf11.hostedemail.com (Postfix) with ESMTP id F411F40004 for ; Thu, 21 Mar 2024 11:52:48 +0000 (UTC) Authentication-Results: imf11.hostedemail.com; dkim=none; spf=pass (imf11.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=1711021969; 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; bh=RoFQvN3A6LuxtEgXr4JZu2gcaE63IfMSc54sFQ64riA=; b=f9XMuJfQRKSxhB1O6QRrwQ6twxDwFtotTHl+jmzV75JD9318z1Z+xF1jgFxfLBjTp9YfQM abm7UUJPS2M42x952tR2UOZgZGMe/XiIFKVdgZ7SS2WpjWs3yjHuWGGjo55RzUa406hfvX SFiYZfATWcVsUtQ9W1F5aLCv5UQ/c8c= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1711021969; a=rsa-sha256; cv=none; b=HI6ZDrTto/4gVDSEypgMwPGhzRWa/ufFFDcHz5H1SoOfLfnpDKifeEcVu+48Zg4z7OPdm2 m/xfe40HtMoh88atjKRFnONkw63SpbBzth4hIoiPsFAVWOg1horGZpTq5VmnfLklZHgvVz zB7rWPFUvmTIVwaI36ZiEoB+5sPDgyE= ARC-Authentication-Results: i=1; imf11.hostedemail.com; dkim=none; spf=pass (imf11.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 6F9BD37307; Thu, 21 Mar 2024 11:52:47 +0000 (UTC) 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 A855013976; Thu, 21 Mar 2024 11:52:46 +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 +W1lJo4f/GVjOgAAD6G6ig (envelope-from ); Thu, 21 Mar 2024 11:52:46 +0000 Date: Thu, 21 Mar 2024 12:54:08 +0100 From: Oscar Salvador To: Vlastimil Babka Cc: Matthew Wilcox , Andrew Morton , linux-kernel@vger.kernel.org, linux-mm@kvack.org, Michal Hocko , Marco Elver , Andrey Konovalov , Alexander Potapenko , Tetsuo Handa Subject: Re: [PATCH v2 2/2] mm,page_owner: Fix accounting of pages when migrating Message-ID: References: <20240319183212.17156-1-osalvador@suse.de> <20240319183212.17156-3-osalvador@suse.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspamd-Queue-Id: F411F40004 X-Rspam-User: X-Rspamd-Server: rspam11 X-Stat-Signature: qnmbgb43inq4xgmn845mhiue1j6buqyg X-HE-Tag: 1711021968-968008 X-HE-Meta: U2FsdGVkX18NI3QcM+8z/2NVvr4KB8XC1er+YRO/DKc3vEl5NqY1py/PAByLi2qj8KdpIpF/JUCzKVlskxPhEhY24OkXDN/i5Rjhp1adpAiw4exubR4mfNXDNQhpLhEbDS7zu+MiDKHYrzpnHT90vKvRhhZJpdvr7qRBwLFzm2kzy8WNsdRkv2mkPhS2cZQbeb6ZmJzYXLrXfphSHGUTopbtUfE3VQDKZieLUtARwsykwqWxjG2TyrnowFyts24sOo4DVR0b4bkv57e8fXeYUdac1UPMTnGdISHy/udqRLCjs+YTQXLjl3fs6xJHqWSqUcBCSoXLLwappHM/F2JMh8WN4op4UTGK4UUwQgo9aCDypNp4F793Xky8eZVljbpRADPPQ92/4GVS65wY1fvY2I8ilasQ5bXMwdqPMjqK7dwl5NmWzWi7mKM7+45FIoYskaaVLYYethpwZFpBLFpbUqpJdOevTa33txvaugH7N8zgMndcXnVXDfNK80r21K5KFnxf2KNqisLw2vQDSpcz/Y6j8jx+2yhsRRphjN1w882GjqNzSmU9cAoALtHVKM5oOQBTA9d03jskQLKTfj5cZPv98ri/BST3S3HattH94l/H98SXcWTV4CJz2p+qZpw0z7dH6G5x7jZde/DBoE+PzzfS9HfhfOKwDjuwFcPoM4qWhW/tGExK/O12NiGFIZt9hdgOtwduZVZoaoRpqLTAuVBRpNotYUYxfvxyTmkKUA6PGKTio735L9IpudachMRfMdFRkeWoBhtrGbs5kHQTqON/IKuDl9QMH4WFlMTtZS5w86QL6ixBBJebyy5LSSQu 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 Thu, Mar 21, 2024 at 12:20:24PM +0100, Vlastimil Babka wrote: > Understood, but migration is kinda heavy and non-fast-path operation already > so the extra lookup wouldn't be in a critical fast path. Ok, you convinced me, let us save that memory. > When I mean is we have __set_page_owner_handle() setting up everything for > tail pages and then we have __folio_copy_owner updating only the head page, > so this will create kinda a mixed up information. Which might not be an > issue as __folio_copy_owner() should mean it's a proper folio thus compound > page thus nobody ever will check those mismatched tail pages... Maybe we > could adjust __set_page_owner_handle() to skip tail pages for compound > pages as well and unify this, and tail pages would be only setup for those > weird high-order non-compound pages so that the odd case in __free_pages() > works? > > Or maybe page_owner is considered debugging functionality enough so it might > be worth having the redundant data in tail pages in case something goes > wrong. But either way now it seems we're not doing it consistently. So we basically have two options here, 1) is to also update tail pages in __folio_copy_owner, and 2) is to follow __folio_copy_owner example and skip tail pages in __set_page_owner. The thing is, going with 2) might mean, as you pointed out, that if something goes wrong we lose the information for those pages as page_owner does not have a record for them. OTOH, would that information be really useful? Sure we could see the stack, but AFAICS not even the migrate_reason would be recorded in those tail pages, which means that if they are migrated and freed, we would only see that they were freed. (the free stack would point to the migrate code though, so that is a hint). Not really sure which path to take here, skipping tail pages would be less of a complexity but at a risk of loosing information. Anyway, let me first tackle the issue at hand here, and then I will think more about that. Thanks! -- Oscar Salvador SUSE Labs