From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp-out2.suse.de (smtp-out2.suse.de [195.135.223.131]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 79AC32C11F1 for ; Tue, 16 Jun 2026 10:08:08 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=195.135.223.131 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1781604490; cv=none; b=alaaGO4qGVL/2Z9eqJjfUzy9+a+L7adrCsAD4tIa3CWjJAJnHz6ldGvnozUvwgnX5f3OEzIRLCiKbyXqFGCeSP90ik3dzQH1yKRVxziHzdkX/OI7zqQysFghxTA56q6jsJbcF5DU3cPggjP4mmz/sn3gR9PsN/j4oX8pNPXyk+o= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1781604490; c=relaxed/simple; bh=UD7klVW3V19e0+ZwYAbe25pvJS8A9esKL0PlyRMY6rM=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=Gi4ssTWfqSDKWkDT2KS8yQT1KV3y0f64J6KSIHDsGcqmmtgTXv1XfEi2axQslQoaBTk8OTRbhM5ugeSoJN4rD9hUCTFlA1ZsYEaxhF2q+8jL/2wPM++aPFz5EUqURlWoN2S5FI7bJwzkL9V2wYXfoJPnqMlxu7uhIVikdrPG4hc= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=suse.de; spf=pass smtp.mailfrom=suse.de; dkim=pass (1024-bit key) header.d=suse.de header.i=@suse.de header.b=ofDK4Hud; dkim=permerror (0-bit key) header.d=suse.de header.i=@suse.de header.b=18vTLxPT; dkim=pass (1024-bit key) header.d=suse.de header.i=@suse.de header.b=ofDK4Hud; dkim=permerror (0-bit key) header.d=suse.de header.i=@suse.de header.b=18vTLxPT; arc=none smtp.client-ip=195.135.223.131 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=suse.de Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=suse.de Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=suse.de header.i=@suse.de header.b="ofDK4Hud"; dkim=permerror (0-bit key) header.d=suse.de header.i=@suse.de header.b="18vTLxPT"; dkim=pass (1024-bit key) header.d=suse.de header.i=@suse.de header.b="ofDK4Hud"; dkim=permerror (0-bit key) header.d=suse.de header.i=@suse.de header.b="18vTLxPT" 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-out2.suse.de (Postfix) with ESMTPS id 62294759DA; Tue, 16 Jun 2026 10:08:06 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_rsa; t=1781604486; 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=cuauUPfvC4hmoS4BXLX+cvp0R7I1il3JNPMPUe7+2EU=; b=ofDK4HudAIGl6fE1OcfWTU840siLa71Qzz9GZWfDLIxWzLIb5NoyThGbdz/JSdzsRAG/fz 9UGz/5qMOxPosv1PRc/Bz8tYen8Sd5V0FBGJ8ADbPGoBt5Rx5/R8muG8t0lKjz3hYB9go7 hq8vMZInMu0IQRTKKFQSDdBYmONN5VY= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_ed25519; t=1781604486; 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=cuauUPfvC4hmoS4BXLX+cvp0R7I1il3JNPMPUe7+2EU=; b=18vTLxPTVhJRf1iR0SYzX9/fDOV400WtKLXU741hhRnaspIpnLnFptog31YlQ6VgZbf9WP M6aqc34f0VZlXcAA== Authentication-Results: smtp-out2.suse.de; dkim=pass header.d=suse.de header.s=susede2_rsa header.b=ofDK4Hud; dkim=pass header.d=suse.de header.s=susede2_ed25519 header.b=18vTLxPT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_rsa; t=1781604486; 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=cuauUPfvC4hmoS4BXLX+cvp0R7I1il3JNPMPUe7+2EU=; b=ofDK4HudAIGl6fE1OcfWTU840siLa71Qzz9GZWfDLIxWzLIb5NoyThGbdz/JSdzsRAG/fz 9UGz/5qMOxPosv1PRc/Bz8tYen8Sd5V0FBGJ8ADbPGoBt5Rx5/R8muG8t0lKjz3hYB9go7 hq8vMZInMu0IQRTKKFQSDdBYmONN5VY= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_ed25519; t=1781604486; 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=cuauUPfvC4hmoS4BXLX+cvp0R7I1il3JNPMPUe7+2EU=; b=18vTLxPTVhJRf1iR0SYzX9/fDOV400WtKLXU741hhRnaspIpnLnFptog31YlQ6VgZbf9WP M6aqc34f0VZlXcAA== 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 A1DE3779A8; Tue, 16 Jun 2026 10:08:05 +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 7vLDIoUgMWqRYAAAD6G6ig (envelope-from ); Tue, 16 Jun 2026 10:08:05 +0000 Date: Tue, 16 Jun 2026 11:08:03 +0100 From: Pedro Falcato To: Yibin Liu Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org, akpm@linux-foundation.org, liam@infradead.org, ljs@kernel.org, vbabka@kernel.org, jannh@google.com, mjguzik@gmail.com, wujianyong@hygon.cn Subject: Re: [RFC PATCH] mm: batch link_file_vma calls in dup_mmap Message-ID: References: <20260616091302.2725675-1-liuyibin@hygon.cn> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20260616091302.2725675-1-liuyibin@hygon.cn> X-Spam-Flag: NO X-Rspamd-Action: no action X-Spam-Level: X-Spamd-Result: default: False [-4.51 / 50.00]; BAYES_HAM(-3.00)[100.00%]; NEURAL_HAM_LONG(-1.00)[-1.000]; R_DKIM_ALLOW(-0.20)[suse.de:s=susede2_rsa,suse.de:s=susede2_ed25519]; NEURAL_HAM_SHORT(-0.20)[-1.000]; MIME_GOOD(-0.10)[text/plain]; MX_GOOD(-0.01)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; FREEMAIL_ENVRCPT(0.00)[gmail.com]; FUZZY_RATELIMITED(0.00)[rspamd.com]; RBL_SPAMHAUS_BLOCKED_OPENRESOLVER(0.00)[2a07:de40:b281:104:10:150:64:97:from]; DKIM_SIGNED(0.00)[suse.de:s=susede2_rsa,suse.de:s=susede2_ed25519]; MIME_TRACE(0.00)[0:+]; ARC_NA(0.00)[]; FREEMAIL_CC(0.00)[kvack.org,vger.kernel.org,linux-foundation.org,infradead.org,kernel.org,google.com,gmail.com,hygon.cn]; DKIM_TRACE(0.00)[suse.de:+]; TO_DN_SOME(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; FROM_EQ_ENVFROM(0.00)[]; FROM_HAS_DN(0.00)[]; RCVD_TLS_ALL(0.00)[]; DWL_DNSWL_BLOCKED(0.00)[suse.de:dkim]; RECEIVED_SPAMHAUS_BLOCKED_OPENRESOLVER(0.00)[2a07:de40:b281:106:10:150:64:167:received]; RCPT_COUNT_SEVEN(0.00)[10]; MISSING_XM_UA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; DBL_BLOCKED_OPENRESOLVER(0.00)[imap1.dmz-prg2.suse.org:helo,imap1.dmz-prg2.suse.org:rdns,suse.de:dkim,hygon.cn:email] X-Rspamd-Server: rspamd2.dmz-prg2.suse.org X-Rspamd-Queue-Id: 62294759DA X-Spam-Score: -4.51 On Tue, Jun 16, 2026 at 05:13:02PM +0800, Yibin Liu wrote: > Forking a process with many file-backed mappings sharing the same > file (e.g. a dynamically linked binary with several mappings into > the same shared library) repeatedly acquires and releases the > mapping i_mmap_rwsem in dup_mmap(), once per vma, as each vma is > inserted into the address_space interval tree. > > Mirror the unlink_file_vma_batch mechanism added for free_pgd_range() > by commit 3577dbb19241 ("mm: batch unlink_file_vma calls in > free_pgd_range") and apply the same idea on the vma creation side: > introduce link_vma_file_batch, which gathers consecutive vmas backed > by the same file and inserts them into the interval tree under a > single i_mmap_lock_write()/i_mmap_unlock_write() pair instead of one > pair per vma. > > Unlike the unlink side, vma_interval_tree_insert_after() needs both > the new vma and the vma it is inserted after, so the batch keeps a > parallel old_vmas[] array alongside new_vmas[] rather than the single > vmas[] array used by unlink_vma_file_batch. > > link_file_vma_batch_add() is wired into dup_mmap()'s vma copy loop in > place of the inline i_mmap_lock_write()/vma_interval_tree_insert_after() > sequence, and link_file_vma_batch_final() flushes any pending batch > both on the successful loop exit and on every error path that jumps > to loop_out, so the interval tree is never left out of sync with the > vmas already linked into the maple tree. > > Tested with the same doexec benchmark used by 3577dbb19241: > http://apollo.backplane.com/DFlyMisc/doexec.c > > $ cc -O2 -o shared-doexec doexec.c > $ ./shared-doexec $(nproc) > > Run on an AMD EPYC 9754 with 512 threads, execs per second improved > by roughly 2%-7% over the unpatched kernel across repeated runs. > > Signed-off-by: Yibin Liu > --- > mm/mmap.c | 14 ++++---------- > mm/vma.c | 49 +++++++++++++++++++++++++++++++++++++++++++++++++ > mm/vma.h | 14 ++++++++++++++ > 3 files changed, 67 insertions(+), 10 deletions(-) > > diff --git a/mm/mmap.c b/mm/mmap.c > index 2311ae7c2..d5a4312df 100644 > --- a/mm/mmap.c > +++ b/mm/mmap.c > @@ -1735,6 +1735,7 @@ __latent_entropy int dup_mmap(struct mm_struct *mm, struct mm_struct *oldmm) > unsigned long charge = 0; > LIST_HEAD(uf); > VMA_ITERATOR(vmi, mm, 0); > + struct link_vma_file_batch vb; > > if (mmap_write_lock_killable(oldmm)) > return -EINTR; > @@ -1758,6 +1759,7 @@ __latent_entropy int dup_mmap(struct mm_struct *mm, struct mm_struct *oldmm) > if (unlikely(retval)) > goto out; > > + link_file_vma_batch_init(&vb); > mt_clear_in_rcu(vmi.mas.tree); > for_each_vma(vmi, mpnt) { > struct file *file; > @@ -1822,18 +1824,9 @@ __latent_entropy int dup_mmap(struct mm_struct *mm, struct mm_struct *oldmm) > > file = tmp->vm_file; > if (file) { > - struct address_space *mapping = file->f_mapping; > - > get_file(file); > - i_mmap_lock_write(mapping); > - if (vma_is_shared_maywrite(tmp)) > - mapping_allow_writable(mapping); > - flush_dcache_mmap_lock(mapping); > /* insert tmp into the share list, just after mpnt */ > - vma_interval_tree_insert_after(tmp, mpnt, > - &mapping->i_mmap); > - flush_dcache_mmap_unlock(mapping); > - i_mmap_unlock_write(mapping); > + link_file_vma_batch_add(&vb, tmp, mpnt); This does not work, it introduces subtly races between rmap and fork(). Consider this: 1) we dup VMA A 2) we copy over the pages 3) concurrently, someone does an rmap walk for the file 4) finally, insert the VMAs into the interval tree The rmap walk will not find every mapping of the folio it's looking at (we haven't inserted the new VMAs yet), and it will be very confused. -- Pedro