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 1BFC6EB64DA for ; Wed, 5 Jul 2023 16:54:23 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 7D9A08D0002; Wed, 5 Jul 2023 12:54:22 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 789618D0001; Wed, 5 Jul 2023 12:54:22 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 651358D0002; Wed, 5 Jul 2023 12:54:22 -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 556FF8D0001 for ; Wed, 5 Jul 2023 12:54:22 -0400 (EDT) Received: from smtpin14.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id 0E6B0C022B for ; Wed, 5 Jul 2023 16:54:22 +0000 (UTC) X-FDA: 80978156364.14.CDDDC14 Received: from wout4-smtp.messagingengine.com (wout4-smtp.messagingengine.com [64.147.123.20]) by imf05.hostedemail.com (Postfix) with ESMTP id A20FD100024 for ; Wed, 5 Jul 2023 16:54:18 +0000 (UTC) Authentication-Results: imf05.hostedemail.com; dkim=pass header.d=shutemov.name header.s=fm1 header.b=I1GlFKAQ; dkim=pass header.d=messagingengine.com header.s=fm2 header.b="N MS+RVB"; dmarc=none; spf=pass (imf05.hostedemail.com: domain of kirill@shutemov.name designates 64.147.123.20 as permitted sender) smtp.mailfrom=kirill@shutemov.name ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1688576059; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to: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=bIBEWDOiL4fJXFNl0WDMqCyWtIZ42p2EH7NI3yU2aBM=; b=l4ThUnGazjdkOWIRWLUhRvS4a9c1xw/HDioN1M5xwiIgHD/W6sXv92Y6EWxk8O1GL1gdMG +Ug8kROeoTF9hAKzpmPhVOgJQXW5poyisSkRQBHNL5ArRZywEcJTKkiDOBaDe3EA7yXz4i /PQoJQwE4M1nUjGr2WwOEmBqv8sHnz4= ARC-Authentication-Results: i=1; imf05.hostedemail.com; dkim=pass header.d=shutemov.name header.s=fm1 header.b=I1GlFKAQ; dkim=pass header.d=messagingengine.com header.s=fm2 header.b="N MS+RVB"; dmarc=none; spf=pass (imf05.hostedemail.com: domain of kirill@shutemov.name designates 64.147.123.20 as permitted sender) smtp.mailfrom=kirill@shutemov.name ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1688576059; a=rsa-sha256; cv=none; b=EH9kS6Yuh8LiI8xf951BQkDqSpRNRDZUDLvLAy1BZM+wpeficnHXiN+GUjn7RihKJkneS4 RnsPoeLWvKPANr7iqeTApJRSrBrUSqH4RQoy3AKgydAH0UNzCDswr3PCqELm/bnV2hjQKI 3qA3RD45XPLeq5PoaEcmUvgNYUJKWk0= Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.west.internal (Postfix) with ESMTP id C47353200917; Wed, 5 Jul 2023 12:54:15 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute4.internal (MEProxy); Wed, 05 Jul 2023 12:54:16 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=shutemov.name; h=cc:content-transfer-encoding:content-type:content-type:date :date:from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:sender:subject:subject:to:to; s=fm1; t= 1688576055; x=1688662455; bh=bIBEWDOiL4fJXFNl0WDMqCyWtIZ42p2EH7N I3yU2aBM=; b=I1GlFKAQoX/Q/3dm7T/b496ijYJbseYeoZ49H8KuWPm3ciwd6iS rskoU9ZyKKIOwoG4ctMy/qOwE559yPN3ENEQ4QCN5sLg6Hec67G8kar73Hk2mJHm pMxFEpWbRzhTMbde09mkC7CY7lo8SZ9rdk9gfhiU48YjpL/WW/Q+yz/rBhJBY70E 4mRJ8emWdEUZ8nK7gScZ4WgjjJI6wEmwgqnSbKOsmXW/dhhCF9tjN6EPjfYL9ytx Iqev5Qv0zWP103zVlDPZ11mNnv/Q5eZWNuUrLxj6hq47WevzK2aSNIaoIcJjCCfL VejQhdbYFDFxKli+hRjhP6QCJVE2z27EKNg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :content-type:date:date:feedback-id:feedback-id:from:from :in-reply-to:in-reply-to:message-id:mime-version:references :reply-to:sender:subject:subject:to:to:x-me-proxy:x-me-proxy :x-me-sender:x-me-sender:x-sasl-enc; s=fm2; t=1688576055; x= 1688662455; bh=bIBEWDOiL4fJXFNl0WDMqCyWtIZ42p2EH7NI3yU2aBM=; b=N MS+RVBjZFD3K9G2MKlYq1XzGdgJkQQEMpViM/E5D+4wF6JLhYxOX0cH2DgVf5Jy/ 5Zg78yDTBiKUeR+7kboFcG3F+YmNZiWlgoViRWKDFF9ov2cOJdu02X42Vfe6tuH6 v3msXnD5LL0gijpkuqVSygFwujnYXmcl79kI8zxfFtLMfFm4Ajmq1UuAy2KqOQAs Av0jVVopyIYe3o2JgtTrr3NNv+KIz7k50sknFuhjPSEHQMGQ7r9aAurIMQUtXEUs GU2NE5mcU2o+YtyWuGkHIsvER2zQReWqqkuAeO5RRgbdfnd1VHQvCPvULGC8CaBt mzC/pAEG0SUqrzhQwhwtg== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedviedrudejgdeiudcutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpeffhffvuffkfhggtggugfgjsehtkedttddttdejnecuhfhrohhmpedfmfhirhhi lhhlucetrdcuufhhuhhtvghmohhvfdcuoehkihhrihhllhesshhhuhhtvghmohhvrdhnrg hmvgeqnecuggftrfgrthhtvghrnhepveettdeuleduveekgfeiudeftdeugfelfeffffek keetieevieeiieeiteetheevnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpe hmrghilhhfrhhomhepkhhirhhilhhlsehshhhuthgvmhhovhdrnhgrmhgv X-ME-Proxy: Feedback-ID: ie3994620:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Wed, 5 Jul 2023 12:54:14 -0400 (EDT) Received: by box.shutemov.name (Postfix, from userid 1000) id 67E251095F9; Wed, 5 Jul 2023 19:54:11 +0300 (+03) Date: Wed, 5 Jul 2023 19:54:11 +0300 From: "Kirill A. Shutemov" To: "Liam R. Howlett" , Yu Ma , akpm@linux-foundation.org, tim.c.chen@intel.com, linux-mm@kvack.org, linux-kernel@vger.kernel.org, dave.hansen@intel.com, dan.j.williams@intel.com, shakeelb@google.com, pan.deng@intel.com, tianyou.li@intel.com, lipeng.zhu@intel.com, tim.c.chen@linux.intel.com Subject: Re: [PATCH] mm/mmap: move vma operations to mm_struct out of the critical section of file mapping lock Message-ID: <20230705165411.tfqqipcla7exkb7k@box.shutemov.name> References: <20230606124939.93561-1-yu.ma@intel.com> <20230606192013.viiifjcgb6enyilx@revolver> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20230606192013.viiifjcgb6enyilx@revolver> X-Rspamd-Queue-Id: A20FD100024 X-Rspam-User: X-Rspamd-Server: rspam02 X-Stat-Signature: 7kois985rt9wtwgzmkfh6zesdgkwehw9 X-HE-Tag: 1688576058-557428 X-HE-Meta: U2FsdGVkX18ibjXG2ofkhUDDLwW6wrJFrZpxcLP/tUyQewhpDrPcUbgrgi5GdLR2LxghyvgusT7REPZ+9G5g4UxjsoNg7fwg5RiQX11T5t7XEfZwIcwri8x0OXHleuMoDhnjz2gN52app97AJcFtHEYaPeltUZHBgL8v5kt807yEZwEKfE8bHSmrZoX9UcbKuxC5GwVDhBkNUbu72jBNHmfxz3a0NX1W7JVmviF/+zchkppfZPvf6X26bNxzFo4CXI14yUfgGyu2p0WCAb0j3hp60olsqo1gyj+qIZJSymPPMtlXgaiMhPA2MmaMwJdvxd8kf/BRxoWBL2kVbKNMivKGPkluxSJPOaYOyDcg7JdqMQK2RFie9HKUtwEVngEX4q/C/SJrI8HIq2UOoD6KzNGU/H2NjCfqLf84H9D8RAY1ZNHX6YF7Zkn/ZVdYORsoelv0BkNMebZN+7e/qbR2kNGE4eqLH4gP9CCuqhQoT8rz2DT7+yeAHGPfwJQMdWrKxVG4pQBbUMxpQ9g441grQKIPaPycRwoUD6ngkJ4/Lbl/JdRfWsVfJarhtfLtK0crTRfrGn5b5f3PpGXt8tMQHd0oKG8caPl3xDo8nHTyJ5kWAhAgBbs2DOXft49GlAzSbylNWLe3+SK1Wtc2VJFQGEen4My2oFAoTSH+q1Iegq9SdFFXStV75T6tnRIIH6G+fmfBUYkVJMhP4ZDF1kW3+FeTFkwyAkddvNlzu8ofXVXfadCwFhqkc2ubH0JTov22DKO/rw8NbXgPF9LLDQm6oISuD7kuycjgzG9FWKptAT8htRUGtc3kzcueBcr8ySChdN3P4NSXegdq/+9Ah4fzSLfS/OCzkcpScclUiHxTyo2j8CIQmCAZy7TcgHKLw+VUEaVK0uUkm8+Qn0qKuLxsC844sbKtLqTC/VDEpbYQe7aI+mefsxzc8fYWDaIeN2zwawEpoquNfgewYLZ0UCp s92n9Q8k e5Hm2kwGkeeGOksrZL/FI7FP2LHtNyMm0O/j2ZiuKZ7vJEXKwRKK5iJn/Wvi2uPQ2/TUdaEcAcFYnzCwDOpe/lajff29qZ2OfHXtndU0/BrW7FXIl0NcXkP/p6PJoPsJPa/OYMjB41S3c2cgIUZWxegiLOQIvZHS/hpuN3gS4bPRn8iirYFRWur6HEZQTmYBCMQB9j9YM7+JAkWEETrirb1SRfQogzQndWTB3QmoamkbtbyddA5DxM5009RiXrbnOxXMCEtBXHa2eSx/QoQF/s//pK0wuXvTJFg4jRFncqvAdEAVT5w7TfJnk6QVDSHufKw/Nd5j22XzoiSJniY4jUG5wWVDE7ofyd+XUigXvWb4sl9QLfyYMM+fnglMeg2h78NgfEIZIdeepmBHwICBfUturOQ== 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: On Tue, Jun 06, 2023 at 03:20:13PM -0400, Liam R. Howlett wrote: > * Yu Ma [230606 08:23]: > > UnixBench/Execl represents a class of workload where bash scripts are > > spawned frequently to do some short jobs. When running multiple parallel > > tasks, hot osq_lock is observed from do_mmap and exit_mmap. Both of them > > come from load_elf_binary through the call chain > > "execl->do_execveat_common->bprm_execve->load_elf_binary". In do_mmap,it will > > call mmap_region to create vma node, initialize it and insert it to vma > > maintain structure in mm_struct and i_mmap tree of the mapping file, then > > increase map_count to record the number of vma nodes used. The hot osq_lock > > is to protect operations on file’s i_mmap tree. For the mm_struct member > > change like vma insertion and map_count update, they do not affect i_mmap > > tree. Move those operations out of the lock's critical section, to reduce > > hold time on the lock. > > > > With this change, on Intel Sapphire Rapids 112C/224T platform, based on > > v6.0-rc6, the 160 parallel score improves by 12%. The patch has no > > obvious performance gain on v6.4-rc4 due to regression of this benchmark > > from this commit f1a7941243c102a44e8847e3b94ff4ff3ec56f25 (mm: convert > > mm's rss stats into percpu_counter). > > I didn't think it was safe to insert a VMA into the VMA tree without > holding this write lock? We now have a window of time where a file > mapping doesn't exist for a vma that's in the tree? Is this always > safe? Does the locking order in mm/rmap.c need to change? We hold mmap lock on write here, right? Who can observe the VMA until the lock is released? It cannot be retrieved from the VMA tree as it requires at least read mmap lock. And the VMA doesn't exist anywhere else. I believe the change is safe. -- Kiryl Shutsemau / Kirill A. Shutemov