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 2B662C2D0CD for ; Mon, 19 May 2025 18:25:52 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id D28396B00BD; Mon, 19 May 2025 14:25:50 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id CB04B6B00D1; Mon, 19 May 2025 14:25:50 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id B52066B00D2; Mon, 19 May 2025 14:25:50 -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 927B46B00BD for ; Mon, 19 May 2025 14:25:50 -0400 (EDT) Received: from smtpin05.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay09.hostedemail.com (Postfix) with ESMTP id D148880D34 for ; Mon, 19 May 2025 18:25:50 +0000 (UTC) X-FDA: 83460486060.05.1886000 Received: from nyc.source.kernel.org (nyc.source.kernel.org [147.75.193.91]) by imf11.hostedemail.com (Postfix) with ESMTP id 3B6C940002 for ; Mon, 19 May 2025 18:25:49 +0000 (UTC) Authentication-Results: imf11.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=OWaSNc+a; spf=pass (imf11.hostedemail.com: domain of sj@kernel.org designates 147.75.193.91 as permitted sender) smtp.mailfrom=sj@kernel.org; dmarc=pass (policy=quarantine) header.from=kernel.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1747679149; 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-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=vRiHK1a/fsg4Rwht5F6ibwF9XMErnPq3bRP+bmbQKzk=; b=6YC3RXj0WkFch+edcmtKYhV9orYG6rzohsBnfzOnVxXDTqssurtY3tu8YHYoM2Jwww5xGT +rrEZxcgGamVomLwNoOoMm17IrnpVwFNyGxM7U7+yVsO4F2wEK1fXqXGEykW+lBj4WRkHU jimv4tMV7d0xF5NWDp7zWyXDx8ekWzA= ARC-Authentication-Results: i=1; imf11.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=OWaSNc+a; spf=pass (imf11.hostedemail.com: domain of sj@kernel.org designates 147.75.193.91 as permitted sender) smtp.mailfrom=sj@kernel.org; dmarc=pass (policy=quarantine) header.from=kernel.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1747679149; a=rsa-sha256; cv=none; b=pOd7ZFH2448cXQTvvp9iFT8bbU2zHhlrqC1wiboG6pBZSPsClJz6LZiiy7qw96/GY9KUtA 3tH7L76CmYsHtDtdIxpimDKSS5tUa3LIkeqd34sQqf3cCI7YXPq/clBdYrjMzrhfqwuXGp 1Fbsu8PoXlm8diMw9di4ceMH7mjZJoo= Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by nyc.source.kernel.org (Postfix) with ESMTP id 8116BA4E7CD; Mon, 19 May 2025 18:25:48 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id E72BFC4CEE4; Mon, 19 May 2025 18:25:47 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1747679148; bh=NIDBPzXUqQ3vtMsBWBp5K7llFn1Vg+0Pe1G6c7OuNEM=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=OWaSNc+a/MGXZl7VvatWyMP1U6uYkMg6Yt9tWz1bxHCCUhWPz5170lWukvKEzixcU 2WlqmJSSiGtyL8VMgxWcfDGqrtrAStpKz63mjf6yj+qRrSXwQZviWcnlpynHuAvYNB yx18mmSYjNCcgllxx6jpxJ/6aGBTbghg6hs9Ln5xVbSSYiHcdmnFu/x865k0IC/4Wq ETTtIz4fy28cSO/kPRppamhby63aCGZAg7RTTAwJTjzcuTt/wmZIWZcZYJRO3HrGGv WmCDK3bgi4VhToYu9ZjzWIuVs2EritLOpJZ1BalQ52bZNLBfvhm9cMaKFh1+DGX9OW 8qdFky4nmdKXA== From: SeongJae Park To: Lorenzo Stoakes Cc: SeongJae Park , "Liam R. Howlett" , Davidlohr Bueso , Andrew Morton , David Hildenbrand , Shakeel Butt , Vlastimil Babka , linux-kernel@vger.kernel.org, linux-mm@kvack.org Subject: Re: [RFC PATCH v2 4/4] mm/madvise: remove redundant mmap_lock operations from process_madvise() Date: Mon, 19 May 2025 11:25:44 -0700 Message-Id: <20250519182544.45603-1-sj@kernel.org> X-Mailer: git-send-email 2.39.5 In-Reply-To: <371ec2c6-01d9-4deb-a234-aacad94680c5@lucifer.local> References: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Rspamd-Server: rspam10 X-Stat-Signature: njbmi1q4jkew1sugjznsi4pmbeoxq74p X-Rspamd-Queue-Id: 3B6C940002 X-Rspam-User: X-HE-Tag: 1747679149-733145 X-HE-Meta: U2FsdGVkX18WsPRbQnVNagGURLkx4BABivnBTZVFfJzJ7WQF77g4yYeJFxXzTAAyWQTXEKU0ZyhFi5LTPxxLH10A3kQrq2S8DVjLYR/V/HxHgPYJvDfHpPjcWfYRKAP8FxMr1UopZ4dIK3icci1yEZRZMVBHkQu6kTHv2TnbKTVn1ipaafLQZgEQgkqGIJ5fi2RZTXabUcgre/KPi8iP7agGxI5zvTs6wsRkkvPTiDpE+bjvkNQbHk1zQryE2rGZ60+IuO0mbJDNzjJU6Gd7w47uALOWfXmd0Nl7S8zDRsb3zMxcQEbiagexh7wuRdQFk95ry10OXAaxf13Z4uyDbC9TlbCT6HyKWqQsz9zhwmkFRqp5QOo5AfjMbUiH5e7afAPZxwb8ZHUnNd4/4E1oXNnqvMSGuKtYTtnA6KOJGpwI7rdwQoym0rJGSB8eIF77iRDBksMQK3m7zZLs6K+06ErnkVHx38xRukpsUFJCp5Mf66hAEnaHKV6luKvF1vpayyA7RFDT2A8+SgovtJAb5Ve/prbGGb1I392cshTtOIbdzi4HCPc2M6w0do3MoxS2p2aIS5tegjFn623UU2Aaw6Gf7AIjHcpd9HigY6CRUYDb5SJ7rgjrP76cXlxXBdyMrYb+GGpT3zHT6blnB4Kt/0EFzJULgnDOzq5PjeUfXqLszqV47LwIQxe1c695g4QtzSMUfNnq1UmUoxb5MqXR+KcpHFr/JADLfPRHv4u2Rd+ElBl8sPfZLWYQOt9opYXpcEgbFGNznSpCbLUiWmLOdkMdbelbtHsWd4TKV1JYbAcLgHExp5WdBDn2qhjxTRM3caCRfVJMX0jZJJ7m9m+ejRo28b23ljuyBRm3Qq5gLI9998iyey2pRKYCv/xE+H6bDxXQest4OixlUpr9ZpzwowMQJopvNeKcu3VstwsTfEP6P3elPmMPzEqUjbSzIn+tDT/buq54l/+cAIqxpE6 XGgpveYU aHDMvATG0K16AS38xfItbkebUaVrvJ/4A+6ftMTUIaxBxzpcby4s3I6x7FcE2N0v17Ck3a0dcj3Ev9HC1PmlK+yzkdphxj9xTsFdCRiSaZv6m5D6AFLCbzfzMadCm/yAWncVLlj+fdjhBhPZQanHZSVKc8ivyKUPphgwExIYFDk3jGsXBOIqrcKg1suMwxfr/vr2qE2aj6DFiDno/I/lul31b6Gyj9vg0oyN9N5+ySOgZbmDmNm3ZDhwWVXg1ISr+m7kI1JxJsUb6NbdDh+kBlQ5XiMDXzoAItrD3ORDgfDIMVO0GtEj4cpypiWM3KhfCbLfNB4WqmY447Yq1MVDBuvJmi0oLtIahXVHrTYEUwe9zYF9QjYkwYCEHanQl55AE/YiJ 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 Sat, 17 May 2025 20:28:49 +0100 Lorenzo Stoakes wrote: > On Fri, Jan 31, 2025 at 05:51:45PM +0000, Lorenzo Stoakes wrote: > > On Fri, Jan 31, 2025 at 12:47:24PM -0500, Liam R. Howlett wrote: > > > * Davidlohr Bueso [250131 12:31]: > > > > On Fri, 31 Jan 2025, Lorenzo Stoakes wrote: > > > > > > > > > On Thu, Jan 16, 2025 at 05:30:58PM -0800, SeongJae Park wrote: > > > > > > Optimize redundant mmap lock operations from process_madvise() by > > > > > > directly doing the mmap locking first, and then the remaining works for > > > > > > all ranges in the loop. > > > > > > > > > > > > Signed-off-by: SeongJae Park > > > > > > > > > > I wonder if this might increase lock contention because now all of the > > > > > vector operations will hold the relevant mm lock without releasing after > > > > > each operation? > > > > > > > > That was exactly my concern. While afaict the numbers presented in v1 > > > > are quite nice, this is ultimately a micro-benchmark, where no other > > > > unrelated threads are impacted by these new hold times. > > > > > > Indeed, I was also concerned about this scenario. > > > > > > But this method does have the added advantage of keeping the vma space > > > in the same state as it was expected during the initial call - although > > > the race does still exist on looking vs acting on the data. This would > > > just remove the intermediate changes. > > > > > > > > > > > > Probably it's ok given limited size of iov, but maybe in future we'd want > > > > > to set a limit on the ranges before we drop/reacquire lock? > > > > > > > > imo, this should best be done in the same patch/series. Maybe extend > > > > the benchmark to use IOV_MAX and find a sweet spot? > > > > > > Are you worried this is over-engineering for a problem that may never be > > > an issue, or is there a particular usecase you have in mind? > > > > > > It is probably worth investigating, and maybe a potential usecase would > > > help with the targeted sweet spot? > > > > > > > Keep in mind process_madvise() is not limited by IOV_MAX, which can be rather > > high, but rather UIO_FASTIOV, which is limited to 8 entries. > > > > (Some have been surprised by this limitation...!) > > Surprised, perhaps because I was wrong about this :) Apologies for that. > > SJ raised this in [0] and the non-RFC version of this series is over at [1]. > > [0]: https://lore.kernel.org/all/20250517162048.36347-1-sj@kernel.org/ > [1]: https://lore.kernel.org/all/20250206061517.2958-1-sj@kernel.org/ I actually mentioned[1] I think the real limit is UIO_MAXIOV but still that wouldn't be a real problem since users can tune the batching size. Actually jemalloc has made a change to use process_madvise() with up to 128 batching size. I impatiently sent[3] the next revision without giving you enough time to reply, though. > > We should revisit this and determine whether the drop/reacquire lock is > required, perhaps doing some experiments around heavy operations using > UIO_MAXIOV entries? > > SJ - could you take a look at this please? We had a chance to test this against a production workload, and found no visible regression. The workload is not intesively calling process_madvise() though. Our internal testing of kernels having this change also didn't find any problem so far, though process_madvise() calls from the internal testing is also not intensive to my best knowledge. So my thought about UIO_MAXIOV is same. I anticipate no issue (until someone yells ;) ) and didn't find an evidence of the problem. But also same to the previous discussion[1], I agree more testing would be good, while I have no good list of benchmarks for this. It would be nice if someone can give me the name of the benchmarks. > > > > > So I think at this point scaling isn't a huge issue, I raise it because in > > future we may want to increase this limit, at which point we should think about > > it, which is why I sort of hand-waved it away a bit. > > Again as I said here, I suspect _probably_ this won't be too much of an > issue - but it is absolutely one we need to address. Yes, I agree :) [1] https://lore.kernel.org/20250204195343.16500-1-sj@kernel.org [2] https://github.com/jemalloc/jemalloc/pull/2794/commits/c3604456d4c1f570348a [3] https://lore.kernel.org/20250206062801.3060-1-sj@kernel.org Thanks, SJ [...]