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 59571CD1284 for ; Tue, 2 Apr 2024 10:26:57 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id A69B26B0095; Tue, 2 Apr 2024 06:26:56 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id A19F26B009B; Tue, 2 Apr 2024 06:26:56 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 8E1466B009C; Tue, 2 Apr 2024 06:26:56 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0015.hostedemail.com [216.40.44.15]) by kanga.kvack.org (Postfix) with ESMTP id 7122C6B0095 for ; Tue, 2 Apr 2024 06:26:56 -0400 (EDT) Received: from smtpin25.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id DD03DA0E14 for ; Tue, 2 Apr 2024 10:26:55 +0000 (UTC) X-FDA: 81964213590.25.CCADF63 Received: from smtp-out1.suse.de (smtp-out1.suse.de [195.135.223.130]) by imf09.hostedemail.com (Postfix) with ESMTP id 95E6C140020 for ; Tue, 2 Apr 2024 10:26:53 +0000 (UTC) Authentication-Results: imf09.hostedemail.com; dkim=pass header.d=suse.cz header.s=susede2_rsa header.b="c3/Aew7R"; dkim=pass header.d=suse.cz header.s=susede2_ed25519 header.b="J+OK/CSv"; dmarc=none; spf=pass (imf09.hostedemail.com: domain of vbabka@suse.cz designates 195.135.223.130 as permitted sender) smtp.mailfrom=vbabka@suse.cz ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1712053614; 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:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=UsqZPy+24oMYT2lO+yB2VXDnHjznmcGdw0YcjOb204o=; b=5PbHn2Rw/E35OXgRrkl48yoTlglOXIwWqqJaL7cho4jnLilrcdQWYtx1BtuV9iVynSqfRB 9Rj/Dt94aCyPCpzK/HSBFKd0yTbn9bk5lk3aVxh/oDcsx+iX+IsOyqWnzL3ukFEyC4m4Hg dHD/0zgGiKrheGgoGrtizrGXjkVhQgA= ARC-Authentication-Results: i=1; imf09.hostedemail.com; dkim=pass header.d=suse.cz header.s=susede2_rsa header.b="c3/Aew7R"; dkim=pass header.d=suse.cz header.s=susede2_ed25519 header.b="J+OK/CSv"; dmarc=none; spf=pass (imf09.hostedemail.com: domain of vbabka@suse.cz designates 195.135.223.130 as permitted sender) smtp.mailfrom=vbabka@suse.cz ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1712053614; a=rsa-sha256; cv=none; b=q9UFJ/RPqIdJ/ioYtCcpRabcmhRSyKgY0jaYNNMnOSfWOQE9ltAffkkfztjPy4RoJhAjmy o5SK5aEoG2EmRJdLvCweeJhniSgeGMpu5zhYQiYYnEYkLKmpHNUE3pJlEeEniVYJpJaEJy Pf0HcgKlUOfba/vLZ1x95PZpoNuftHo= 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 1980834583; Tue, 2 Apr 2024 10:26:52 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.cz; s=susede2_rsa; t=1712053612; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=UsqZPy+24oMYT2lO+yB2VXDnHjznmcGdw0YcjOb204o=; b=c3/Aew7Rs4mdHLOk5Jc6KLh6wLveDiD9l+S9NpQ9u1vHFW8N3srNpN/1R74L07LiS/Y1KE aoQrxYTOXCZP9xQRY3G57KsmCvFA5ZTklQecxr2jvUn14NOKiIpk6vYOOKnpj8U1f4lzjQ ibIYUEHiuSY1hzwtfuthlyeuqVJhAlw= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.cz; s=susede2_ed25519; t=1712053612; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=UsqZPy+24oMYT2lO+yB2VXDnHjznmcGdw0YcjOb204o=; b=J+OK/CSvXNWRf2bGQFKD2+SWhtkn244KMnJ5dJg17SZOJVmm96+OyCSanTMV4AEokgXU9Q R/JaBST64QnCUOCw== 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 0289013A90; Tue, 2 Apr 2024 10:26:51 +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 9A4EAGzdC2bUFAAAn2gu4w (envelope-from ); Tue, 02 Apr 2024 10:26:51 +0000 Message-ID: <50f31489-b5c3-480e-a7db-20edbbb2c9c2@suse.cz> Date: Tue, 2 Apr 2024 12:26:51 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v3 3/3] mm,page_owner: Fix accounting of pages when migrating Content-Language: en-US To: Oscar Salvador , Andrew Morton Cc: linux-kernel@vger.kernel.org, linux-mm@kvack.org, Michal Hocko , Marco Elver , Andrey Konovalov , Alexander Potapenko References: <20240326063036.6242-1-osalvador@suse.de> <20240326063036.6242-4-osalvador@suse.de> From: Vlastimil Babka In-Reply-To: <20240326063036.6242-4-osalvador@suse.de> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 95E6C140020 X-Rspam-User: X-Rspamd-Server: rspam05 X-Stat-Signature: 4hbdf5fzsj7r7guc6w4mofauczxcdxie X-HE-Tag: 1712053613-263824 X-HE-Meta: U2FsdGVkX1+/gAFBVxEVepwsBU+uZliDA3dAMHhBbRcQ6qBsiQzlDrILawhrm56cJt3UeDkdFoF1ucuiFxCYp323RtsGcslaylpurZ5VgXD6NRe/+qlKZPlTA/EQS7vyO/BiBsYdUlP/W+R1O7o17qS1GnKQGWl4T3q3uOrxY8GSOrf7RHcjufrNYFuyPleUelXUnxSRAB+OlIob74prpmzXOdYvEOIhFIHdizYKig+V24o8G43b9PJd/X8NbAudSJURNSNAPzN6NlsbbPM+EBWLMpHXg+GEH1t1ZHpSbyPdfQDybRnp2efQARPv2QnbmOlK2uWMyVdkDPa5DjaEFVBsE24jLAUy0ARUjOlcJkEEBxAwdRARXL+No2lEVoayzAdfvgFK2Tm5dlRAcSr5+Z/M0uR9WU1On5a+/Infc6eBu88IIxyvXTgVguiM+m7Bp6prDdJzUmPRLs0N6ynPJPdliTQeTqWiz18RQ26WJsZ4r3i/cPlQT5RCkvDDVyQQMtG+aT4MVGlEWR4iSaxkUR+RSanpHcpzt+UqiHjyTyOPq/FxPxT1w7Wys8uMA0nCdWtQ0FkoBRu3BC+ZwUgZ5ldSWVz5ShtdCfdMPbHx/IFqXCW9DuUViUaKY+jKV04wYLzJM8C/m8JEWMDOtOOvcFl5wCneBcO6q0oi9kyM9Eyq/l8V1+q5oaPyJ5Q2BLBpohcS43wkGrDmyV7/cFqj67z5C9PS5It/qkK7qhpkfPVb4ZBq3DQmE1Qwzsx8wDsz2ZwkrEsze1MqmzM056/P1mud4Q2jxmGojEwlfT2rS1Vy+hAur21HquL1MUd3WAWElgSq7bMrdPuEUKmlZBVbobjZLo+xsq4Hr3h78kj3mj36Ko17S5hYRgLuOwxpj06+bkX5c1/gYd7G2ucrPAkEVflCVVluL2wSKg3Y62On5fAmipF1jubXEWfc06N3nxX/1uMt6TLFtjrtFEdJB0S Td35aRtM bJtNbEeT6soAVr9pD7vIRlmJxEfmkKp0vhw5dyNAEE/RigPYs9QwKygzc4Bgzr7E+sbEFfOCv3j5IfhMBooeZbfuvA9V0UzPcPN2OYdEmGr20weGIiwzIZCIgfg/SfetSQOnRfde/zB1szVf5eM0g9QXgPTMgzYgn2AafEqhGhDf19kBKNxOpTwBItbim4r4fNFO6Ojb9TJimQ42GQ1n7M/8RJJV2KwSpGnttrVldvAmSkJY4JrAa6eJ2LDYaswQ4dM25cfMguXJZgQHCbbBYvTfEDi4QmXMUkyD8SFyGcvQSITUKPam52nE1rA== 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 3/26/24 7:30 AM, Oscar Salvador wrote: > Upon migration, new allocated pages are being given the handle of the old > pages. This is problematic because it means that for the stack which > allocated the old page, we will be substracting the old page + the new one > when that page is freed, creating an accounting imbalance. > > There is an interest in keeping it that way, as otherwise the output will > biased towards migration stacks should those operations occur often, but > that is not really helpful. > The link from the new page to the old stack is being performed by calling > __update_page_owner_handle() in __folio_copy_owner(). > The only thing that is left is to link the migrate stack to the old > page, so the old page will be subtracted from the migrate stack, > avoiding by doing so any possible imbalance. > > Fixes: 217b2119b9e2 ("mm,page_owner: implement the tracking of the stacks count") > Signed-off-by: Oscar Salvador > --- > mm/page_owner.c | 15 +++++++++++++++ > 1 file changed, 15 insertions(+) > > diff --git a/mm/page_owner.c b/mm/page_owner.c > index 5df0d6892bdc..b4476f45b376 100644 > --- a/mm/page_owner.c > +++ b/mm/page_owner.c > @@ -366,9 +366,12 @@ void __split_page_owner(struct page *page, int old_order, int new_order) > > void __folio_copy_owner(struct folio *newfolio, struct folio *old) > { > + int i; > struct page_ext *old_ext; > struct page_ext *new_ext; > struct page_owner *old_page_owner; > + struct page_owner *new_page_owner; > + depot_stack_handle_t migrate_handle; > > old_ext = page_ext_get(&old->page); > if (unlikely(!old_ext)) > @@ -381,6 +384,8 @@ void __folio_copy_owner(struct folio *newfolio, struct folio *old) > } > > old_page_owner = get_page_owner(old_ext); > + new_page_owner = get_page_owner(new_ext); > + migrate_handle = new_page_owner->handle; > __update_page_owner_handle(new_ext, old_page_owner->handle, > old_page_owner->order, old_page_owner->gfp_mask, > old_page_owner->last_migrate_reason, > @@ -395,6 +400,16 @@ void __folio_copy_owner(struct folio *newfolio, struct folio *old) > old_page_owner->free_pid, > old_page_owner->free_tgid, > old_page_owner->free_ts_nsec); > + /* > + * We linked the original stack to the new folio, we need to do the same > + * for the new one and the old folio otherwise there will be an imbalance > + * when subtracting those pages from the stack. > + */ > + for (i = 0; i < (1 << new_page_owner->order); i++) { > + old_page_owner->handle = migrate_handle; > + old_ext = page_ext_next(old_ext); > + old_page_owner = get_page_owner(old_ext); > + } Can the migration still fail after __folio_copy_owner()? That goes again to the comment you changed in patch 1/3. If it can, this will kinda create a mess with the old folio's handles not reflecting reality? (although refcounts will be ok) So if that case is possible, could we instead just dec_stack_record_count() for the handle that allocated the new folio (IIUC "migrate_handle" here) and inc_stack_record_count() for the original handle that we duplicated from the old to new. Then if either old is freed (successful migration) or new is freed (failed migration), we'll have the correct refcounts. > > page_ext_put(new_ext); > page_ext_put(old_ext);