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 94517CD1284 for ; Tue, 2 Apr 2024 10:13:42 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 2E4246B0088; Tue, 2 Apr 2024 06:13:42 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 293B16B0092; Tue, 2 Apr 2024 06:13:42 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 15B886B0095; Tue, 2 Apr 2024 06:13:42 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0014.hostedemail.com [216.40.44.14]) by kanga.kvack.org (Postfix) with ESMTP id ECD3D6B0088 for ; Tue, 2 Apr 2024 06:13:41 -0400 (EDT) Received: from smtpin06.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay09.hostedemail.com (Postfix) with ESMTP id 8094F80977 for ; Tue, 2 Apr 2024 10:13:41 +0000 (UTC) X-FDA: 81964180242.06.72FD8D5 Received: from smtp-out2.suse.de (smtp-out2.suse.de [195.135.223.131]) by imf06.hostedemail.com (Postfix) with ESMTP id 17A50180009 for ; Tue, 2 Apr 2024 10:13:38 +0000 (UTC) Authentication-Results: imf06.hostedemail.com; dkim=pass header.d=suse.cz header.s=susede2_rsa header.b=w4ywbHRJ; dkim=pass header.d=suse.cz header.s=susede2_ed25519 header.b=vXATRa89; spf=pass (imf06.hostedemail.com: domain of vbabka@suse.cz designates 195.135.223.131 as permitted sender) smtp.mailfrom=vbabka@suse.cz; dmarc=none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1712052819; 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=njSlSGOMqBKNspEV8hCCFGcHqk6Kp8tl6U12MEOcK30=; b=HDIAxvX2KjtYPojZUbjZwvJYu0Vp0rhqMqu1q8KC1LHeDHwzigBqktmZbyAgYZa3WQIOUf 17sfG/qF7DO1rtcgYjkH9VEq9KpSdEXcYLfzoec5i1X9RsS58/lUvcc72FQ9OljXVFgDCF c9BvZV9EuTC9BvYIsC+0qTQATP2xBV0= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1712052819; a=rsa-sha256; cv=none; b=PVDEqINtbJ8em2l/ZKOYeDBgb40204oOChay2f2abGW3TmN6z7URRePWwCHLCnBAsR/+4l Ty/82V5Y+Uo6/Kgv1+SualPJZv8N/OA84FDd5XI0wX/HA34Yb4HbcNyoE725F2DHGUZ6QZ KRM718yQb62xR2WGiT0/fGqoM+K4Fyk= ARC-Authentication-Results: i=1; imf06.hostedemail.com; dkim=pass header.d=suse.cz header.s=susede2_rsa header.b=w4ywbHRJ; dkim=pass header.d=suse.cz header.s=susede2_ed25519 header.b=vXATRa89; spf=pass (imf06.hostedemail.com: domain of vbabka@suse.cz designates 195.135.223.131 as permitted sender) smtp.mailfrom=vbabka@suse.cz; dmarc=none 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-out2.suse.de (Postfix) with ESMTPS id 7B61620F47; Tue, 2 Apr 2024 10:13:37 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.cz; s=susede2_rsa; t=1712052817; 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=njSlSGOMqBKNspEV8hCCFGcHqk6Kp8tl6U12MEOcK30=; b=w4ywbHRJHXHA595W2TmolBE+GoC4lQpd7D3ugWhG7HFeWG9P0wVr72QxVfv2b2NnZB3slV wtcosM3tkverf23koiL3ADiSuJYUHBhOK+DvG3zuzWuLVcKNN2SGPDEw3O1azKT0vK+muG vx01hxGCvkGIActugoepzogcafXLlno= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.cz; s=susede2_ed25519; t=1712052817; 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=njSlSGOMqBKNspEV8hCCFGcHqk6Kp8tl6U12MEOcK30=; b=vXATRa89zGM3jg+gaEqtjs49i8HxOmuwTfQoACMMBIqviAm4kikj1M7FE8vyLUKMPm19w5 haphp9lEjifTJKDA== 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 662BF13A90; Tue, 2 Apr 2024 10:13:37 +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 LjZxGFHaC2YyEAAAn2gu4w (envelope-from ); Tue, 02 Apr 2024 10:13:37 +0000 Message-ID: Date: Tue, 2 Apr 2024 12:13:37 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v3 1/3] mm,page_owner: Update metada for tail pages 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-2-osalvador@suse.de> From: Vlastimil Babka In-Reply-To: <20240326063036.6242-2-osalvador@suse.de> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Rspamd-Action: no action X-Stat-Signature: hp6chmxojfb9apnpzt4y1n6phy8bt4yy X-Rspamd-Server: rspam10 X-Rspamd-Queue-Id: 17A50180009 X-Rspam-User: X-HE-Tag: 1712052818-938738 X-HE-Meta: U2FsdGVkX18FCPPTMFFcpotfFTQyLGhaFWlh2ETG0cwIwp+vMV/6WlrTNAGZrPiK5jUxJOXl+XnZMbDnDhkvyayQZnoiHaoUtEmm/6GhkJvf3Ew3Cm+c7OFOkomeVE46+iWrVtU1SDxUnVJs1DaP5hkTVQvHRS4k0JfzH1Q464bhMLBkylmDjm8/yJqGqbAgKPC/SlYMEip7RZOvJmCS/pxuYb8BFJ1DuYPk9HCGYddt5Z85srBV8zF2nco6hacGhQysKG+B7t7lYqNMaByE98WqEwgLW12Adzq9bXZErSW1oQ1wWQmc12ixP37Wu34JozBS1ec0QaXaKhLS3O7MmkFCyhNYa3IHXql5Zw4vrdAYBifTu/d3nzBGUrOi2pDwufFrBGG5xb9+G0YpOzmKkJo6DTK4U55cBfOfyX5Mp80wN4IjxW075V4fUBEXE+o7bxnUB2WV8wnOoz51EUHKknEkV1pW29YraFMgdlDxafMkYrBuXdzz2jmRiwXr1v48TJS+ONdRiFwa4cEl98zOiiHlMoBglOxBCVNG583QgmOAhiNG0q7G+2405NDaX2CsJcqVwkvDelPsTn1cPAT9eyLbn39eA7FllPEmM0ee2QKUDJJwvnp8eI2qRLCVJK6e5ggU++CKZITnJ84JxBLA4/VUY81jsOsEpDUMlyB61uceNtKJSKA8Hk7yryeSacsro/7oVZ9y3ZB+t67GyBIubyBKVePY3Y+gAFgCeznphMzuy1ZOEeVr/ahieKb58TlEEUghbuwbe/F9WgvgRzoPXqf/l+2eiOmE6d23DwvJNuKl0awdaLuP46mff8Y1HprDLg2FnUYvdj7nYCnkNXVq+dAw935/Jd6TaDfJ/mP2u84lzVQ/NKGgM6UtUixq+0ehbiTHjUb8RwDCsaCafZWlUJom2VFIKH47wa3VwDpLheRrrsL3Q6i3fv0BoWzfqZaNTnWZQu4VuVWpX4vCCzB 0yn6FH/v OAajCIQIBDFEU6GiOoaLeCldEIStOEVLBAmKPDBu7c8rcwZMdSyY/0X2a8NftB+VJSliHYI4z99SCfXST5ucO/37FvhNZdSZdF3BL51+Inul45UTYJFm33gYnAeCwI2ueOu2hbO+S2BLYAx4kS0G090YaIo4GGYqoVhUV96ssAKhjuNfZV6TOTmhpvWjWsW9/NpH+NBER3k1yufAq8SIaxyE0OUo9TjBdbsLmt2QXQlkpyNseAzG8hQjyFeniiod+HBF7EHHGMsURs6+B5mIkptYmiaQaZ5pNeDY4wk5/s0uB2Xu19g7hPW2nnA== 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: Subject: metada -> metadata On 3/26/24 7:30 AM, Oscar Salvador wrote: > __set_page_owner_handle() and __reset_page_owner() update the metadata > of all pages when the page is of a higher-order, but we miss to do the > same when the pages are migrated. > __folio_copy_owner() only updates the metadata of the head page, meaning > that the information stored in the first page and the tail pages will not > match. > > Strictly speaking that is not a big problem because 1) we do not print > tail pages and 2) upon splitting all tail pages will inherit the > metada of the head page, but it is better to have all metadata in check metadata > should there be any problem, so it can ease debugging. > > For that purpose, a couple of helpers are created > __update_page_owner_handle() which updates the metadata on allocation, > and __update_page_owner_free_handle() which does the same when the page > is freed. > > __folio_copy_owner() will make use of both as it needs to entirely replace > the page_owner metadata for the new page. > > Signed-off-by: Oscar Salvador Reviewed-by: Vlastimil Babka Also I think this series should move to mm-hotfixes due to fixing bugs from rc1. Some more nits: > @@ -355,31 +375,21 @@ 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); > - new_page_owner->order = old_page_owner->order; > - new_page_owner->gfp_mask = old_page_owner->gfp_mask; > - new_page_owner->last_migrate_reason = > - old_page_owner->last_migrate_reason; > - new_page_owner->handle = old_page_owner->handle; > - new_page_owner->pid = old_page_owner->pid; > - new_page_owner->tgid = old_page_owner->tgid; > - new_page_owner->free_pid = old_page_owner->free_pid; > - new_page_owner->free_tgid = old_page_owner->free_tgid; > - new_page_owner->ts_nsec = old_page_owner->ts_nsec; > - new_page_owner->free_ts_nsec = old_page_owner->ts_nsec; > - strcpy(new_page_owner->comm, old_page_owner->comm); > - > + __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, > + old_page_owner->ts_nsec, old_page_owner->pid, > + old_page_owner->tgid, old_page_owner->comm); > /* > - * 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? > - __set_bit(PAGE_EXT_OWNER, &new_ext->flags); > - __set_bit(PAGE_EXT_OWNER_ALLOCATED, &new_ext->flags); > + __update_page_owner_free_handle(new_ext, 0, old_page_owner->order, > + old_page_owner->free_pid, > + old_page_owner->free_tgid, > + old_page_owner->free_ts_nsec); > + > page_ext_put(new_ext); > page_ext_put(old_ext); > } > @@ -787,8 +797,9 @@ static void init_pages_in_zone(pg_data_t *pgdat, struct zone *zone) > goto ext_put_continue; > > /* Found early allocated page */ > - __set_page_owner_handle(page_ext, early_handle, > - 0, 0); > + __update_page_owner_handle(page_ext, early_handle, 0, 0, > + -1, local_clock(), current->pid, > + current->tgid, current->comm); > count++; > ext_put_continue: > page_ext_put(page_ext);