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 58125C54E67 for ; Wed, 20 Mar 2024 04:58:47 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id B15D46B0083; Wed, 20 Mar 2024 00:58:46 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id AC7016B0085; Wed, 20 Mar 2024 00:58:46 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 967126B0088; Wed, 20 Mar 2024 00:58:46 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0011.hostedemail.com [216.40.44.11]) by kanga.kvack.org (Postfix) with ESMTP id 8434E6B0083 for ; Wed, 20 Mar 2024 00:58:46 -0400 (EDT) Received: from smtpin15.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay07.hostedemail.com (Postfix) with ESMTP id 44648161038 for ; Wed, 20 Mar 2024 04:58:46 +0000 (UTC) X-FDA: 81916212252.15.F6EC234 Received: from smtp-out1.suse.de (smtp-out1.suse.de [195.135.223.130]) by imf24.hostedemail.com (Postfix) with ESMTP id 0897518000D for ; Wed, 20 Mar 2024 04:58:43 +0000 (UTC) Authentication-Results: imf24.hostedemail.com; dkim=pass header.d=suse.de header.s=susede2_rsa header.b=tmFJC3bt; dkim=pass header.d=suse.de header.s=susede2_ed25519 header.b=f4tnpDq7; dkim=pass header.d=suse.de header.s=susede2_rsa header.b=tmFJC3bt; dkim=pass header.d=suse.de header.s=susede2_ed25519 header.b=f4tnpDq7; dmarc=pass (policy=none) header.from=suse.de; spf=pass (imf24.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=1710910724; 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=BqYdbsJiVpvaV5yrL8Yc783Zl0AzPQgiCsn8hCQDOJI=; b=nBxfoMtXQVb+HwnWqRJ4CNeEcoRnyqyw4ITKqH+YP7NW8yovQ0wKyoMQJ3qu8KoHg6wh4o L3SrxZnTe3hqggcY77yrU13b/a5s+jA2gsFT73hd/15gHqqY1cdv0i1YZK7YnbDRqPGUB7 C/GZ4os1nZtMcEyNOkePNX4NrLoZ3gA= ARC-Authentication-Results: i=1; imf24.hostedemail.com; dkim=pass header.d=suse.de header.s=susede2_rsa header.b=tmFJC3bt; dkim=pass header.d=suse.de header.s=susede2_ed25519 header.b=f4tnpDq7; dkim=pass header.d=suse.de header.s=susede2_rsa header.b=tmFJC3bt; dkim=pass header.d=suse.de header.s=susede2_ed25519 header.b=f4tnpDq7; dmarc=pass (policy=none) header.from=suse.de; spf=pass (imf24.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=1710910724; a=rsa-sha256; cv=none; b=xLdaD1N/Z0j1HMwaQGiFjz4EaIMV1msg1zPsWeML8E5swF5WcuQxxs+qsPj/ZNVEa1zYvK P6GB9rEjy/ZdAivGSld9m4xlr1g8Od5tPZ2XoQ3r4TrfLrsRPUW5leWX/SlFgQt+0AgsP3 apUmaUq6OpRZ+VAPUxqUoL0hv1j3F/0= Received: from imap1.dmz-prg2.suse.org (imap1.dmz-prg2.suse.org [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 431A333C71; Wed, 20 Mar 2024 04:58:42 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_rsa; t=1710910722; 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=BqYdbsJiVpvaV5yrL8Yc783Zl0AzPQgiCsn8hCQDOJI=; b=tmFJC3btkNKCvknVBScweVzqTZ/ZwgpxjqUoKCApKTNgKBqH1uUXxu0zGnxEXjKr539T6W RM2f1cbexQ1Gnzb9m3pU0vh2GHFxJqDFkkn2CIWGQtK9AHrqPwNmmHOSOAB2kYubPb4c6Q 3/ZQSR/4WGbjoUnsu7RhGCB3ex8OQ7M= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_ed25519; t=1710910722; 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=BqYdbsJiVpvaV5yrL8Yc783Zl0AzPQgiCsn8hCQDOJI=; b=f4tnpDq7IW+3FIeuvZxWJwUNAxhFF80ux6aaoJohyIz9QE+gP7uZ3HoyW8F9lT4CT2TDPP SAjlnE9EGtkY+yCA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_rsa; t=1710910722; 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=BqYdbsJiVpvaV5yrL8Yc783Zl0AzPQgiCsn8hCQDOJI=; b=tmFJC3btkNKCvknVBScweVzqTZ/ZwgpxjqUoKCApKTNgKBqH1uUXxu0zGnxEXjKr539T6W RM2f1cbexQ1Gnzb9m3pU0vh2GHFxJqDFkkn2CIWGQtK9AHrqPwNmmHOSOAB2kYubPb4c6Q 3/ZQSR/4WGbjoUnsu7RhGCB3ex8OQ7M= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_ed25519; t=1710910722; 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=BqYdbsJiVpvaV5yrL8Yc783Zl0AzPQgiCsn8hCQDOJI=; b=f4tnpDq7IW+3FIeuvZxWJwUNAxhFF80ux6aaoJohyIz9QE+gP7uZ3HoyW8F9lT4CT2TDPP SAjlnE9EGtkY+yCA== 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 9F17A136CD; Wed, 20 Mar 2024 04:58:41 +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 HyMHJAFt+mW0fwAAD6G6ig (envelope-from ); Wed, 20 Mar 2024 04:58:41 +0000 Date: Wed, 20 Mar 2024 06:00:08 +0100 From: Oscar Salvador To: Matthew Wilcox Cc: Andrew Morton , linux-kernel@vger.kernel.org, linux-mm@kvack.org, Michal Hocko , Vlastimil Babka , 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-Rspam-User: X-Rspamd-Server: rspam12 X-Rspamd-Queue-Id: 0897518000D X-Stat-Signature: 3967dznna5bm3zor4cf89x5mgwniz4hx X-HE-Tag: 1710910723-678169 X-HE-Meta: U2FsdGVkX19YtIvezPmsHmof1KZedOib3SqHe6AVAVSGrjtdY6wIlyDxxhP+dLA3cS/vynuBAREyxFjzLDhodIfC4trqauJvtEr0DITKtgRJFh4l7boer9O71y8dBBXCTWkQ3bLc/uy3T6LLscOAYMevObwxO5tzXoND4Q5KQHSvGK1VtbSGWdKiv+FK+MGt+vjiYm4SkbX0OvxZrPawk/cfi/0gpKRGZAUJvjTLdcNuzPRm5plGSDRzjlmia3Nx3N0XrBHTmSoVhX4eU8dPIwgYY9pfI9f9BGWF+Z9X4SgJRrYQfUxg/lHpzAP6lXXblz1WaQDsbrC2wE7SW3I8SMhPjmYELlejPXV4wdydz/WxSKBYH5DDeIA4DUZfpB5wevlODBXSArtrhy34LzPLx0qb0ubILxnteGqc6bcxOOssHjhukVpczPvO+15zcPpPVvNEpMbvxroA2GH1qHYZf2DGMRvaggxqcAcGg4MPztXbmx4zWYh2fuEBnglkz2bPP4OvY6iSIKDyr0sgaBEcnhfdMRAFfXwVeotTn6mEkda5sVTQ7mBke1MdX1pyxS6DMThlkNPXjLMRkvhjWDm0RWXpjd/0SW4ToA6zkJAMQxOowrrGsiWpgiDC5eRBAXam40S10WGRS/rEZQnuu9DDoWJzIfqsiXBFmEjUf9FU5uzlX/vvA2Y57ifox0UW6Xyb5ampRlyQOAYwz/mHZQONPVuATMbrq5UalRoqw6wUQxIOBo33gurD9qo6H5i1ZQ9fkijnShf1iQIHhA6hY2PZzoGeUhqKE3lFLACSe9PKH9ycBPT+R6zJdbFZRie2+S1BZTCL83/q5QmbE0eAENfq2Ah9tEGfSkgOcGkkxF2VEEbmFVxE5FMiLVrP8aJrWLyDN8cDgACwdZONnDe835MEeWFZ1G/PjiJlUfMV1h4ofptnFcQ6zfoE3S1ZAD/we9SIed/uJLcAggKrk1ivdY2 f59+mjB5 SQR5BbvYNxCpuv1+oXboZIfAMNs1FRQvZSYldOHimKtjlenjBaJYJmZUVk9M1qINMWCnqbTWmD1JmlJeami0+Fi1h3ekDT1Fo2IPiv4mvPfzQmEpwZonecwBwGvIgLCv/7bXYrQkuSSNjyaICFR6TcxsKAddqQAPlQxWSb9cz9cg6At7ZPBghTVJcmykhxJC/m9hGhWaV7VhsB+wyb6KTseVwuvUY6AlaY62SyvDuMyvlV4s0BrtQJZlJsenbUQFJVlW6 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, Mar 19, 2024 at 06:48:31PM +0000, Matthew Wilcox wrote: > Is this the right way to fix this problem? I would have thought we'd > be better off accounting this as migration freeing the old page and > allocating the new page. If I understand correctly, this is the code > which says "This page was last allocated by X and freed by Y", and I > would think that being last freed (or allocated) by the migration code > would be a very nice hint about where a problem might stem from. I hear you, and I had the same thought when I stumbled upon this. I did not know that the handle was being changed, otherwise it would have saved me quite a lot of debugging time. Checking the history of this, I can see this decision was made in 2016 in: commit d435edca928805074dae005ab9a42d9fa60fc702 Author: Vlastimil Babka Date: Tue Mar 15 14:56:15 2016 -0700 mm, page_owner: copy page owner info during migration And let me quote: "The page_owner mechanism stores gfp_flags of an allocation and stack trace that lead to it. During page migration, the original information is practically replaced by the allocation of free page as the migration target. Arguably this is less useful and might lead to all the page_owner info for migratable pages gradually converge towards compaction or numa balancing migrations. It has also lead to inaccuracies such as one fixed by commit e2cfc91120fa ("mm/page_owner: set correct gfp_mask on page_owner")." A following patch stored the migration reason in last_migrate_reason, and the patch also add a bit of information if last_migrate_reason was other than 0: + if (page_ext->last_migrate_reason != -1) { + ret += snprintf(kbuf + ret, count - ret, + "Page has been migrated, last migrate reason: %s\n", + migrate_reason_names[page_ext->last_migrate_reason]); + if (ret >= count) + goto err; + } Now, thinking about this some more, it kind of makes sense, because one of the things page_owner is used for, in my experience, is for memory leaks. We print the output, try to correlate allocation/free operations per stack so one can easily spot a stack that just keeps allocating memory and never frees it (it might be legit, and not a leak, but it gives a hint). Now imagine there are 10k pages pointing to stack A. If those pages were to be migrated e.g: kcompactd jumps in, we will lose the original stack and replace it with something like: migrate_pages() ... ... kcompatd After that, stack A does not have those 10k pages pointing to it anymore, although it stills "own" them, just that got replaced by new ones due to migration. This kind of defeats the purpose of page_owner. And after all, we do record some migration information in those new pages, which will give us a hint when looking at the output. So, all in all, I am leaning towards "this is fine". -- Oscar Salvador SUSE Labs