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 73814C02180 for ; Wed, 15 Jan 2025 07:15:40 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id D26876B0082; Wed, 15 Jan 2025 02:15:39 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id CAEB16B0083; Wed, 15 Jan 2025 02:15:39 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id B4F4A6B0088; Wed, 15 Jan 2025 02:15:39 -0500 (EST) 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 958426B0082 for ; Wed, 15 Jan 2025 02:15:39 -0500 (EST) Received: from smtpin30.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay07.hostedemail.com (Postfix) with ESMTP id 22EE616089F for ; Wed, 15 Jan 2025 07:15:39 +0000 (UTC) X-FDA: 83008825998.30.E5A75F6 Received: from invmail4.hynix.com (exvmail4.hynix.com [166.125.252.92]) by imf06.hostedemail.com (Postfix) with ESMTP id 5E2D0180008 for ; Wed, 15 Jan 2025 07:15:36 +0000 (UTC) Authentication-Results: imf06.hostedemail.com; dkim=none; dmarc=none; spf=pass (imf06.hostedemail.com: domain of honggyu.kim@sk.com designates 166.125.252.92 as permitted sender) smtp.mailfrom=honggyu.kim@sk.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1736925337; a=rsa-sha256; cv=none; b=UBFt1n/mflhknozE3QxvVflvEDYzTe/vs5+QC3/TkczcVRKbFyo00RLMc9pel63EMuSsTC qTPaIJfaADTPs7lmdY0gKu9k/tGBKNS1lYXx0jguRW+Zxz6kc1oJtOfoclzDCPXik/me7o Ob4LZiAbqW/62VOuOL123judKbMuMNg= ARC-Authentication-Results: i=1; imf06.hostedemail.com; dkim=none; dmarc=none; spf=pass (imf06.hostedemail.com: domain of honggyu.kim@sk.com designates 166.125.252.92 as permitted sender) smtp.mailfrom=honggyu.kim@sk.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1736925337; 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:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=8stEmzKMK1HjlhIw2DOKHrhfv6AieB1T6LLlw41pgeE=; b=U0VuJYqPC1vx+T8gNH0XjPCh3ocXDruNkyZaKFA0cdNoqauf9WrY6RZSidIzfpCGwd2Joz wYXgej1F8RrsneQaOaVCnSVT6Mr+Qa7qyHOoINvBRD55o7mVsuvyR7LLLnW5MMHrD3jBn+ dpnmicb2Pq4ETrmH1RHMR0XLQs5Scak= X-AuditID: a67dfc5b-3e1ff7000001d7ae-93-67876096efa2 Message-ID: Date: Wed, 15 Jan 2025 16:15:34 +0900 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Cc: kernel_team@skhynix.com, Andrew Morton , Jens Axboe , Pavel Begunkov , damon@lists.linux.dev, io-uring@vger.kernel.org, linux-kernel@vger.kernel.org, linux-mm@kvack.org, lorenzo.stoakes@oracle.com, Liam.Howlett@oracle.com Subject: Re: [RFC PATCH] mm/madvise: remove redundant mmap_lock operations from process_madvise() Content-Language: ko To: SeongJae Park References: <20250115061910.58938-1-sj@kernel.org> From: Honggyu Kim In-Reply-To: <20250115061910.58938-1-sj@kernel.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupikeLIzCtJLcpLzFFi42LhesuzSHdaQnu6wY7HChZz1q9hs5izahuj xeq7/WwWT/7/ZrV413qOxWJ7wwN2i8u75rBZ3Fvzn9Xi5KyVLBaHv75hcuDy2DnrLrvH5bOl HptWdbJ5bPo0id3jxIzfLB4vNs9k9Pj49BaLx+dNcgEcUVw2Kak5mWWpRfp2CVwZM9ZeYC94 K1bRf/8MUwPjRqEuRg4OCQETiZkzE7oYOcHMm3f3MoKEeQUsJabN5wUxWQRUJZ4fDAWp4BUQ lDg58wkLiC0qIC9x/9YM9i5GLg5mgbVMEjOmTmEGSQgLJEtMv3OQDcRmFhCRmN3ZBhYXEVCU OPf4IiuILSRgJHHy9xqwQWwCahJXXk5iAtnFKWAs8f1fPUSrmUTX1i5GCFteYvvbOcwguyQE XrNJrH47jRHiZEmJgytusExgFJyF5L5ZSFbPQjJrFpJZCxhZVjEKZeaV5SZm5pjoZVTmZVbo JefnbmIExtCy2j/ROxg/XQg+xCjAwajEw3shvi1diDWxrLgy9xCjBAezkgjvErbWdCHelMTK qtSi/Pii0pzU4kOM0hwsSuK8Rt/KU4QE0hNLUrNTUwtSi2CyTBycUg2Moi+Pe/88486y0fZK XhxTcPzM1eXXvcqULuzOPrPNWMRx9d8codmtV0JEVhf0iDes3vYkMtq9nPukxbMjSWyTT1xQ mr92D4P9f5mr9581HgzRbTr+6QJTn5XyDHH29YbFH+VLftuar7kY8kNE6/TWwFL5v/GXRTgS l5m4F1nNnKx7bM37Xb/MlViKMxINtZiLihMBHWf0NZ0CAAA= X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrELMWRmVeSWpSXmKPExsXCNUNLT3daQnu6wappYhZz1q9hs5izahuj xeq7/WwWT/7/ZrV413qOxeLw3JOsFtsbHrBbXN41h83i3pr/rBYnZ60ESnx9w+TA7bFz1l12 j8tnSz02repk89j0aRK7x4kZv1k8Xmyeyejx8ektFo/FLz4weXzeJBfAGcVlk5Kak1mWWqRv l8CVMWPtBfaCt2IV/ffPMDUwbhTqYuTkkBAwkbh5dy9jFyMHB6+ApcS0+bwgJouAqsTzg6Eg FbwCghInZz5hAbFFBeQl7t+awd7FyMXBLLCWSWLG1CnMIAlhgWSJ6XcOsoHYzAIiErM728Di IgKKEuceX2QFsYUEjCRO/l4DNohNQE3iystJTCC7OAWMJb7/q4doNZPo2trFCGHLS2x/O4d5 AiPfLCRnzEKyYRaSlllIWhYwsqxiFMnMK8tNzMwx1SvOzqjMy6zQS87P3cQIjIlltX8m7mD8 ctn9EKMAB6MSD++JiLZ0IdbEsuLK3EOMEhzMSiK8S9ha04V4UxIrq1KL8uOLSnNSiw8xSnOw KInzeoWnJggJpCeWpGanphakFsFkmTg4pRoYtzzpXvyi377+pZWLhxzLb9/LR3ZsW/RYtiz0 Z0au3oR9HWLP+VunPDlo/YM79kznW7dkk6kf2Hcm3V3JV/HJv5lPgktJzPRFUNiG35s3r5Pb 0M66YlOxT/J1YeuImdFay6o6Q7Ru2BtLtkRskHrsnqeWLBxU2yP0rP3KnUy2vfViOayXxLYo sRRnJBpqMRcVJwIA58YCEoUCAAA= X-CFilter-Loop: Reflected X-Stat-Signature: xrgm86mhozmrqpz5dbojauz7878aj3yn X-Rspam-User: X-Rspamd-Queue-Id: 5E2D0180008 X-Rspamd-Server: rspam08 X-HE-Tag: 1736925336-973213 X-HE-Meta: U2FsdGVkX1+JmKkSJQ+GYOPFbMUwLx8ED6LezOaKEEPZCKZrN8FrnpcTqTF9+fVBLoCrP74oCltEdCO5T7naCuDHhl6fXSCavW0i3kblClmTNjRkA5JYltWqwpq/mQQ0yDOVIOUWfPZ/Pg/m0O+vFtOkIQCC4e4oKh8FU0Q6+PYNgpe0yX+vN7DY0GWCVBuH8ydyvrufm1XAHpLRFL9ksHSBqgQ8r0/6+bOC9iwLVq0T2G1AiGZEZx/WHvEKJwI1z7WgCuiajPPSQUR7BQ/jMEoT6hMKHSxLoxOH65hQi0vfM/XcEAvpql3nL36HBPuW5nzPplkX9XIrj/S8xOCoFi0tvMEsTX0ZH7z2hjygmLWqeNUcTbzlJynoMR5ks2hFvlUogc4KqXfkK84mUBotmTLPH1Z0P2anllczLsvWrnA7dqTaLduuTTRRKmdjcV62cb/4jC3pMryr5JC8GbsxYMC2/vFiFcMRDMCA3Kz5TlVTxDWAqqhh7bCKGf8vfuc/ppFVRiv6wwILiKY0/PkBTWhKRujjmjPt/WfA2t+DOaIYoZN28qfQAUHuMhjI7Z1VfJmks1U1aoO5G4f1IQ4J+HIZGhxII6SnfkuKTuVE//wbD4vzHJtu/O6t4rUkZ0TvOZ9DF+7j7z2uvmotbUJ+f8Jl0CZlFNdmdM0VLCsRQpAU/J/sdunPMy0oTaCV/Ubf8vVjBH+68PgbyRPEpYubcYucHoRM7w7yNcTVrxJ/ERc/ZiB/H30dPMGi+0IgAeLv4lC2z1uvyVmagUljvYg3Nfy9+tfFZ/tbiZS2oS3uiTtEIOOW2W+Q30d0DG9ZSCLGHt9e0dHDeNpXCzSZJVnx9VSVKjPXNdpl8EHuqVFkh8tPlYkqTiV0f8RbXXhGXqRHuzsQkSwjMENz3d4Tz+Rx30boia7NeUeeq0iBMRWM0sK7SHf6BI6ui4Y2qLf+ryYc474dMPj2uwP5tkJegFn 8I6o+yJL u+O+1MBFMoVvxO1ocqYjCp7bbOJrDE4d7XCQewfVJ7eAWYNZQXzMwgPtpUzAIF4xXjk5H3akN45xAZjQBu6OvU+DIzd8sYNCrc02QAgGaQdpeCZAAb66mlVrfws4rxGmUji9rzmzk9DfO6nWJoXYX0JxJj0hLOeiISFGqeiGCGQdUj2tOy+Hh6Cou5H82GGYh1KDj5lBDw6HW/ZSOksxrAkFc2HrzLj/jISXR 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: Hi SeongJae, I'm resending this because my new mail client mistakenly set the mail format to HTML. Sorry for the noise. On 1/15/2025 3:19 PM, SeongJae Park wrote: > Hi Honggyu, > > On Wed, 15 Jan 2025 13:35:48 +0900 Honggyu Kim wrote: > >> Hi SeongJae, >> >> I have a simple comment on this. >> >> On 1/11/2025 9:46 AM, SeongJae Park wrote: >>> process_madvise() calls do_madvise() for each address range. Then, each >>> do_madvise() invocation holds and releases same mmap_lock. Optimize the >>> redundant lock operations by doing the locking in process_madvise(), and >>> inform do_madvise() that the lock is already held and therefore can be >>> skipped. > [...] >>> --- >>> include/linux/mm.h | 3 ++- >>> io_uring/advise.c | 2 +- >>> mm/damon/vaddr.c | 2 +- >>> mm/madvise.c | 54 +++++++++++++++++++++++++++++++++++----------- >>> 4 files changed, 45 insertions(+), 16 deletions(-) >>> >>> diff --git a/include/linux/mm.h b/include/linux/mm.h >>> index 612b513ebfbd..e3ca5967ebd4 100644 >>> --- a/include/linux/mm.h >>> +++ b/include/linux/mm.h >>> @@ -3459,7 +3459,8 @@ int do_vmi_align_munmap(struct vma_iterator *vmi, struct vm_area_struct *vma, >>> unsigned long end, struct list_head *uf, bool unlock); >>> extern int do_munmap(struct mm_struct *, unsigned long, size_t, >>> struct list_head *uf); >>> -extern int do_madvise(struct mm_struct *mm, unsigned long start, size_t len_in, int behavior); >>> +extern int do_madvise(struct mm_struct *mm, unsigned long start, size_t len_in, >>> + int behavior, bool lock_held); >>> >>> #ifdef CONFIG_MMU >>> extern int __mm_populate(unsigned long addr, unsigned long len, >>> diff --git a/io_uring/advise.c b/io_uring/advise.c >>> index cb7b881665e5..010b55d5a26e 100644 >>> --- a/io_uring/advise.c >>> +++ b/io_uring/advise.c >>> @@ -56,7 +56,7 @@ int io_madvise(struct io_kiocb *req, unsigned int issue_flags) >>> >>> WARN_ON_ONCE(issue_flags & IO_URING_F_NONBLOCK); >>> >>> - ret = do_madvise(current->mm, ma->addr, ma->len, ma->advice); >>> + ret = do_madvise(current->mm, ma->addr, ma->len, ma->advice, false); >> >> I feel like this doesn't look good in terms of readability. Can we >> introduce an enum for this? > > I agree that's not good to read. Liam alos pointed out a similar issue but Right. I didn't carefully read his comment. Thanks for the info. > suggested splitting functions with clear names[1]. I think that also fairly > improves readability, and I slightly prefer that way, since it wouldn't > introduce a new type for only a single use case. Would that also work for your > concern, or do you have a different opinion? > > [1] https://lore.kernel.org/20250115041750.58164-1-sj@kernel.org I don't have any other concern. Thanks, Honggyu > Thanks, > SJ > > [...]