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 0DEEDC02193 for ; Fri, 31 Jan 2025 19:17:21 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 45C336B0082; Fri, 31 Jan 2025 14:17:21 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 397336B0083; Fri, 31 Jan 2025 14:17:21 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 238416B0085; Fri, 31 Jan 2025 14:17:21 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0011.hostedemail.com [216.40.44.11]) by kanga.kvack.org (Postfix) with ESMTP id 029456B0082 for ; Fri, 31 Jan 2025 14:17:20 -0500 (EST) Received: from smtpin29.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id 9C6591C7B7D for ; Fri, 31 Jan 2025 19:17:20 +0000 (UTC) X-FDA: 83068705440.29.2AAE1BB Received: from out-185.mta1.migadu.com (out-185.mta1.migadu.com [95.215.58.185]) by imf10.hostedemail.com (Postfix) with ESMTP id 2F95DC000D for ; Fri, 31 Jan 2025 19:17:16 +0000 (UTC) Authentication-Results: imf10.hostedemail.com; dkim=pass header.d=linux.dev header.s=key1 header.b=VoNnT4D8; spf=pass (imf10.hostedemail.com: domain of shakeel.butt@linux.dev designates 95.215.58.185 as permitted sender) smtp.mailfrom=shakeel.butt@linux.dev; dmarc=pass (policy=none) header.from=linux.dev ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1738351039; 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: in-reply-to:in-reply-to:references:references:dkim-signature; bh=xb9vx+i3/j7E+ZJZlUO26diQjP2jWbKmw33LsH60EFQ=; b=aBvbGiu1hNPLMHuVfxocsfouFsTr/vo96SofgY35ol5lARfuvc3O7AF0XUYdeYN1P3KKmX R8zE4vWUZ6p8lwGTQlEY4zm2OddDLc8VWQANS1PfRno5NBgRqj299z7zg0LgT7mO4Suet6 Ozmpvs9JcAmM8BkbBK9Csojr6cS1AZw= ARC-Authentication-Results: i=1; imf10.hostedemail.com; dkim=pass header.d=linux.dev header.s=key1 header.b=VoNnT4D8; spf=pass (imf10.hostedemail.com: domain of shakeel.butt@linux.dev designates 95.215.58.185 as permitted sender) smtp.mailfrom=shakeel.butt@linux.dev; dmarc=pass (policy=none) header.from=linux.dev ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1738351039; a=rsa-sha256; cv=none; b=SnbFmNXiB6m/X0Y1oVdQ+5KRj/Fnl2KXpLGTNHFpe66h8ik+LGvTELuW33n/MQecfuv4KJ hYqpVZfrQU8nXIBgjCC94zhvQqoP0+5I86LYwDcuSi70Rk3mWc8vKRWoJY4JK9an90SvlO FVNBWu+O1Llwze31k+4Y6lv1/dK94Vk= Date: Fri, 31 Jan 2025 11:17:07 -0800 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.dev; s=key1; t=1738351033; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=xb9vx+i3/j7E+ZJZlUO26diQjP2jWbKmw33LsH60EFQ=; b=VoNnT4D8EQRl/F1SNHKZ8SgmJxynUcxK0Ct0DoCeNhjBywjd57zM8Svhx6d7YhJRDdUdHX 0TBntXMpcv/A3mmy7b3YsnKjgodSn5MyT1lVzCIiABVLNDlzNUAEF13NAurrghfQMvpjkY pIVTAg3Hjo4Mo+1i+nrw7T5DNM3Ghio= X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. From: Shakeel Butt To: "Liam R. Howlett" , Davidlohr Bueso , Lorenzo Stoakes , SeongJae Park , Andrew Morton , David Hildenbrand , 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() Message-ID: References: <20250117013058.1843-1-sj@kernel.org> <20250117013058.1843-5-sj@kernel.org> <20250131173132.uqjwrzj7e5vx2sbv@offworld> <7k2gs6xmx2q7la6kle5xpn2p2f6bccbiv5lrdowp5hnecxpijx@rzwxdhcl6mc2> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <7k2gs6xmx2q7la6kle5xpn2p2f6bccbiv5lrdowp5hnecxpijx@rzwxdhcl6mc2> X-Migadu-Flow: FLOW_OUT X-Rspamd-Server: rspam02 X-Rspamd-Queue-Id: 2F95DC000D X-Stat-Signature: zsqafbwnpps7e6bzji136aib8ngq93ci X-Rspam-User: X-HE-Tag: 1738351036-361721 X-HE-Meta: U2FsdGVkX1/Z4QM4PxOCdsPszu7qTJdyYAD4fRFZifEd1bYR3O2q5KT1phncHGbXQqa0nO5XM3SXNrP/OcgttCqhIlt9LjftBHbXb/+hWT6srWtfBBvOiL6WO95eh9oJecgFBnx2ty30rK1Qw/uXqw6CGT6CtCX8OY3imVAt4c5rBlkqcnFmtWiOMIOY04Q0tOpkk10MK/hsezz1nf5XFEIXsiBKGmLohCI9U0aY4fGziVbCZECj38U/XvMPfLx8uf4M5+OJt/SIazn8kREH7xiWubmFjsmczVumz1Q4cuxgAq0EoiUPsHbFvHZ1pF7/699iMWBUwIWfL4Mm0flelcRSMv4OBvdH/Szr4dJPFs3onFMMM3ahrqWerESYTSrjjgUjYwZA3wW89JRUOrzstPaE+d8MlWHy8rEeOeyumt5Dmrrg/Ld537Er7jW/YPOOjv0yPcyxbgusHEktJmyUR96fzMAGACVpzBuUrgP4WbNhHynuutnmxYN/TUhRcEVt5EExvqBPpzUDoA/muCXbDv2AV/psihDnijsSqjqpk6Ax6NrZJhrdEvroH/F/VyCdl2ch9h4EWPGY+XJrEiiODiotG7J5iRh+LYM2spORbI+ZHLv98tV6g5y7KF+kWLKErG5qwP63rqW+d6CNenXDkEBewFa9dpDwDFicddHlZNUCmCORH5Rj/giLiOSSdya8ICUcVAAQIF4KeoVxIc0qsMqx7i7uIYrXs1pBKjppQsuitRvhbTk/Ze/8NW4trO7PUXdNlXyOxDzRXlj6/E7k9vsaaOSQ4VwpYKKXF6r+ujVeR8xjsfqa79qhY3gQ3USINSZ3Pf25rdoJMkH426bWwKDDhfPjrHQ9F4TSo4IsngI0duNLCsBKpSSaOxSBqk4iNyGI0FQGMVj+lmVSMRVd6+8to1TfooXjrRBLH4qHI2Zqi8wIapqUyCrcHKsqLTA1Jku8xQ7zlaLm539a2Xp t/9MsItD TJoMaCi/geU+DFJzxvKtFgl9jQVrsCbprVvlibp0k+1UxfsrmoGiPYterFuINsucoPrU07n31BWDoKM0wj8fZqNubgHvHOlXd6UGRRjtndvGEHBRJc0MrUPzUH6mBBUXfQ/SMJmraDLVqOvHxATPFN1Jux3ysr9Xz0uQyMuR/gjrSggz8aupg6PFLgyKJJptHkRVEqbJbrrO2R1fWI4Lo4Mn997io4wesg7KO70O3xpI/jpEeI/ymCCtog1U6E4LMe3B2qrAJrkRppaDmiFsr6BiqAuO/FFbTPQiOr5H+q/7zjVCKKdZIdKGYDA== 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 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? > > Lorenzo already explained that it is not an issue at the moment. I think this is good discussion to have as I think we will be expanding the limit from UIO_FASTIOV to higher value (maybe UIO_MAXIOV) soon in the followup. At the moment, my gut feeling is that batch size of regions given to the syscall will depend on the advise parameter. For example, For MADV_[NO]HUGEPAGE which is a simple flag [re]set, a single write lock and possible a single tree traversal will be better than multiple write lock/unlock operations even for large batch size. Anyways we will need some experimental data to show that. JFYI SJ is planning to work on two improvements: (1) single tree traversal for all the given regions and (2) TLB flush batching for MADV_DONTNEED[_LOCKED] and MADV_FREE. Thanks everyone for your time and feedback.