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 117ACC71157 for ; Tue, 17 Jun 2025 08:34:25 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id A5D386B007B; Tue, 17 Jun 2025 04:34:24 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id A0DE76B0089; Tue, 17 Jun 2025 04:34:24 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 8FCE46B0092; Tue, 17 Jun 2025 04:34:24 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0010.hostedemail.com [216.40.44.10]) by kanga.kvack.org (Postfix) with ESMTP id 8259C6B007B for ; Tue, 17 Jun 2025 04:34:24 -0400 (EDT) Received: from smtpin30.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay04.hostedemail.com (Postfix) with ESMTP id 3727E1A1ADF for ; Tue, 17 Jun 2025 08:34:24 +0000 (UTC) X-FDA: 83564230848.30.BF021A1 Received: from smtp-out1.suse.de (smtp-out1.suse.de [195.135.223.130]) by imf23.hostedemail.com (Postfix) with ESMTP id ED53F140007 for ; Tue, 17 Jun 2025 08:34:21 +0000 (UTC) Authentication-Results: imf23.hostedemail.com; dkim=pass header.d=suse.de header.s=susede2_rsa header.b="0ck4Q/F5"; dkim=pass header.d=suse.de header.s=susede2_ed25519 header.b=miTE9ltY; dkim=pass header.d=suse.de header.s=susede2_rsa header.b=L514i8N4; dkim=pass header.d=suse.de header.s=susede2_ed25519 header.b=v80wN1rX; spf=pass (imf23.hostedemail.com: domain of pfalcato@suse.de designates 195.135.223.130 as permitted sender) smtp.mailfrom=pfalcato@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=1750149262; 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=v0mmCPaQMbEkfA0unyPUw+wVSwuzYmJHSzmnf7b3Waw=; b=DrBoO51e97yfXIf35FQa4GyMHDOCNU6gPa16jxnULYZkN0cOpAbXHBdtxcD5XXZtnpov5i g7OvAXTE/ed7eEtKet3ipBlNiimNz5HPGFb6mOA0vh3VpxIkQSzEGydXOxkA78HOVPXkYa OhJd1TOq/RNeh6hqKI6KaEBXGVd76PQ= ARC-Authentication-Results: i=1; imf23.hostedemail.com; dkim=pass header.d=suse.de header.s=susede2_rsa header.b="0ck4Q/F5"; dkim=pass header.d=suse.de header.s=susede2_ed25519 header.b=miTE9ltY; dkim=pass header.d=suse.de header.s=susede2_rsa header.b=L514i8N4; dkim=pass header.d=suse.de header.s=susede2_ed25519 header.b=v80wN1rX; spf=pass (imf23.hostedemail.com: domain of pfalcato@suse.de designates 195.135.223.130 as permitted sender) smtp.mailfrom=pfalcato@suse.de; dmarc=pass (policy=none) header.from=suse.de ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1750149262; a=rsa-sha256; cv=none; b=PhDA8x2gIfkSly98G+fO6Zml+GMJV5EIrRgGX256aRek4rk/pY2bm0Ojym49JYiCsd1iL8 jOGtevsgXvrojKgONuHAIjAGkWPYQxGXkqBhVXDFjE7tGQhPlB3buYhouFW6BieHo0G+7A oigdRYL3tObyGRBGAAYkgnhXb2E8yT0= 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 56E1021167; Tue, 17 Jun 2025 08:34:19 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_rsa; t=1750149260; 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=v0mmCPaQMbEkfA0unyPUw+wVSwuzYmJHSzmnf7b3Waw=; b=0ck4Q/F5ZFfM2le3kVL2BqSEcBlDDcCkIgWkX0D2CBSgYPn9EYqqNmxYo/rZAknwkqfEbq UE/ikKMxG9wKe0B6ySxcTWjgq4xv01TAmZegoR+rX8r3mpj6dBhNVSbMgcLdgYI8HYvpui gKnPfwttS2MTquYgu+sFJkQ6lL6a8UE= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_ed25519; t=1750149260; 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=v0mmCPaQMbEkfA0unyPUw+wVSwuzYmJHSzmnf7b3Waw=; b=miTE9ltYQi8gGJMaTYGsZvvp5rsT+Pzx4criIUSHgXc9+NXmj/sdLQ2PPt+OuvawRlbu0E ywYaVpAitj/FDKAw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_rsa; t=1750149259; 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=v0mmCPaQMbEkfA0unyPUw+wVSwuzYmJHSzmnf7b3Waw=; b=L514i8N4Z4wNUpFToMOgORvlG42pQYMuCHyywo56QjI4y8wYz0HSkxJvVrkD9htynUj2ky 5DH5hceCPedSMsVr/jPnAnppjPT+55PLNT7AYePNIGPyTC08QXXOTchNqKwF4PSTcHKZAT OjHYMwSeroaqvJnMON/+vgY+SxdTapQ= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_ed25519; t=1750149259; 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=v0mmCPaQMbEkfA0unyPUw+wVSwuzYmJHSzmnf7b3Waw=; b=v80wN1rX3wmQrONkQFz1I5pl/eEECWCojk/RcqJzteRBBbAaz5sv/5ZJiPBTL5+g2E6nZJ i9MhAn9DdXKk9YCQ== 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 2A64013A69; Tue, 17 Jun 2025 08:34:18 +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 Vm0xB4ooUWgHeQAAD6G6ig (envelope-from ); Tue, 17 Jun 2025 08:34:18 +0000 Date: Tue, 17 Jun 2025 09:34:16 +0100 From: Pedro Falcato To: David Hildenbrand Cc: Lorenzo Stoakes , Andrew Morton , Vlastimil Babka , Jann Horn , "Liam R . Howlett" , Suren Baghdasaryan , Matthew Wilcox , Rik van Riel , Harry Yoo , Zi Yan , Baolin Wang , Nico Pache , Ryan Roberts , Dev Jain , Jakub Matena , Wei Yang , Barry Song , linux-mm@kvack.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH 00/11] mm/mremap: introduce more mergeable mremap via MREMAP_RELOCATE_ANON Message-ID: <76zi626uk53dtfzmezzt6cfz45ansam2gpcumddqxnipnw5jkh@qwfzoxgi255b> References: <7e51e1e2-7272-48d5-9457-40ab87ad7694@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspamd-Action: no action X-Rspamd-Queue-Id: ED53F140007 X-Rspamd-Server: rspam07 X-Stat-Signature: fy5dwpbusm5tnt5qxcpa94tz5ysi1ycq X-Rspam-User: X-HE-Tag: 1750149261-416530 X-HE-Meta: U2FsdGVkX1/SYrbByIKoIZ+b/VqtUgniPbQEcKFlOTEYz3gIKLLs/WF0CcObRMbfmZYZFxIy61l3UQ6qGsXr6lbNuttTO5HwHUMalLY5kFn3pqXMT/RpifA8MCkQ5xaM1f3tCUYrKKIz7Rl07sVkxZ4+StjvBhR3+PWlu8HVATlusrm2iU7WQV8zAzfCOzUl3ESVOtzCU/TLYydzIBWHoUjBrxLmVPMsLE82OzcZfPkzj6g5hu78XHWi6dVqkPbzVx1m2bhbqjyufcITAf5+zcnamkFL+PwNsYhQAVQSNwztamtFrreD3dIy/TQTwv1uiM35/vX4VJ7FjVVCOn/NUKSzXZzM+G9t0yIjiHV1tXG5adDyJA8Dob0Rz6N11KUylpkFdfjVe+XqffYiwt+9rwitNWsSnIsOMtcmkMFzsdhGQ7JthEa91cNbUsyB6L147qSE0waUvZFsyi4NAlm/l25j44nbYX27hJyK+9nfEdMoTWOvLORLvip252frA4eGl+uJ6h1hhX6EcbVPkKY5IMRBwgLF4tF2Sv9zoFUXHDDDBELlhHE8fU9S1i6EnUc4+Tckd5L//OjOJmqU0/VxExul8Wqndfu9UFuTKpi0yGy1g0TKAimqKCtKM9VvD1IcyPVcv3984mkxJse2CBwvBMufwuol8UGMwjjjhrARP6ZZ+REghKNc4MVzVmgEjt6Tajy5MkJ5PHIOLaEZTqVHo1lvxXE8Ns5G2MRaerL5bKRHdPTpCoQc7GemjL+Me4jwWI5eBYcx8UVfUFfDinkEBdx1m4Ms3fgam6vCmUaNUmGW+5VnK+Kq3zBY2Ksz0ibl7iAYqaeKp4GBrxeLXdRpX0nUulc2yidGAsMQrfm1nOmQM4xO9SgD0wipND4Fec7SiNnT1FJ8miNZXeNzJdOWERd0Z4wGBqQCxfthtV+/g9mdQ28qoHqT8UQmCc47wnI+BgcuZVf/SB4mXROY1y1 3Pkr0TDn XeSzogIqQQ8itrXaKfGALRH9y17XP/U+urmYndbGIWFbvZ61wCXyUoHNmAkcowIT87RthorBwnP2Iev7EtqwiNxtx4v6KLU/DiawJRqxmvBehjgQVZ9git4EL6rSzZjCKLsG4TUXivh7ji+e3xOZDHkP3AdwN6kP50HIH+tdnr12gnVvxLeA/6ieU6rclsRKyCegTArExoB9vGRNfi4UHbk7AIIRAf397M5IR3fyL/7QoT6rY27IemyjdwfjXsHz7h4gXwsiJjf16xVRdfBC3tvJYuIHK8oP8K0peppAby7MK7Jd3/LZiXgCGYDF9uU4c1ezxM6EASjam3N1Hb5ULZwHgK5nb+ed2Mw6knUcV+xhDpfyl6b24AwyQwXqJU0+8TtVWzg76jwEdbwqEexXk8LD7XgkfuIIgsjuubU5vHteuDwM= 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 Mon, Jun 16, 2025 at 10:41:20PM +0200, David Hildenbrand wrote: > On 16.06.25 22:24, David Hildenbrand wrote: > > Hi Lorenzo, > > > > as discussed offline, there is a lot going on an this is rather ... a > > lot of code+complexity for something that is more a corner cases. :) > > > > Corner-case as in: only select user space will benefit from this, which > > is really a shame. > > > > After your presentation at LSF/MM, I thought about this further, and I > > was wondering whether: > > > > (a) We cannot make this semi-automatic, avoiding flags. > > > > (b) We cannot simplify further by limiting it to the common+easy cases > > first. > > > > I think you already to some degree did b) as part of this non-RFC, which > > is great. > > > > > > So before digging into the details, let's discuss the high level problem > > briefly. > > > > I think there are three parts to it: > > > > (1) Detecting whether it is safe to adjust the folio->index (small > > folios) > > > > (2) Performance implications of doing so > > > > (3) Detecting whether it is safe to adjust the folio->index (large PTE- > > mapped folios) > > > > > > Regarding (1), if we simply track whether a folio was ever used for > > COW-sharing, it would be very easy: and not only for present folios, but > > for any anon folios that are referenced by swap/migration entries. > > Skimming over patch #1, I think you apply a similar logic, which is good. > > > > Regarding (2), it would apply when we mremap() anon VMAs and they happen > > to reside next to other anon VMAs. Which workloads are we concerned > > about harming by implementing this optimization? I recall that the most > > common use case for mremap() is actually for file mappings, but I might realloc() for mmapped allocations commonly calls mremap(), FYI (at least for glibc, and musl; can't bother to look at the rest). > > be wrong. In any case, we could just have a different way to enable this > > optimization than for each and every mremap() invocation in a process. /me thinks of prctl :P FWIW, with regards to the whole feature: While I do understand it's purpose ( relocating anon might be too much for most workloads, but great for some), I'm uncomfortable with the amount of internals we're exposing here. Who's to say this is how mm rmap looks in 20 years? And we're stuck maintaining the userspace ABI until then. Personally, I would prefer if we just had a flag 'MREMAP_HARDER' that would vaguely be documented as "mremap but harder, even if have to do a little more work". Then we could move things around without promising RELOCATE_ANON makes conceptual sense, and userspace wouldn't have to think through the implications of such a flag by reading Lorenzo's great book. -- Pedro