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 DC998C02180 for ; Wed, 15 Jan 2025 04:17:58 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 6166F280002; Tue, 14 Jan 2025 23:17:58 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 5C6F86B0092; Tue, 14 Jan 2025 23:17:58 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 4B6BD280002; Tue, 14 Jan 2025 23:17:58 -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 2D1136B008C for ; Tue, 14 Jan 2025 23:17:58 -0500 (EST) Received: from smtpin22.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay04.hostedemail.com (Postfix) with ESMTP id BF5EF1A0FF1 for ; Wed, 15 Jan 2025 04:17:57 +0000 (UTC) X-FDA: 83008378194.22.5CC4354 Received: from nyc.source.kernel.org (nyc.source.kernel.org [147.75.193.91]) by imf08.hostedemail.com (Postfix) with ESMTP id 2323516000F for ; Wed, 15 Jan 2025 04:17:55 +0000 (UTC) Authentication-Results: imf08.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=YZb3M3pK; dmarc=pass (policy=quarantine) header.from=kernel.org; spf=pass (imf08.hostedemail.com: domain of sj@kernel.org designates 147.75.193.91 as permitted sender) smtp.mailfrom=sj@kernel.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1736914676; 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=o2WG29fNHXU5PHmnk4zNQHR1LtfQ9riG6vVhCeSWFnk=; b=IEffqvJGdRblivTg5kxJ6rMTk44oteLnszyvxFwfP3i/tfFwKAkdva67F7sqk0jy3y484e ocIzvCnaxV/SMHM/hJGUi41zJRzYoNRvagmNovavqA4xaNh9OBF6/pbtEgeZ64nZVtYqRH eVRXbl9bf96K8IYpS1Ks4597GlmRJUs= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1736914676; a=rsa-sha256; cv=none; b=nkPbRfSxWpWPDf4WUfV2MLwg2YIdYQQuUY4+IdmSYocx5JS37hG4ZXYUeEHzLymUK20vvP rZ4LBSBGDXHTT39AJgGf54F6lXw9il/LGmaacwAiBjleNQKLTfTctS689Sx9Trvyw+5vPr RZ4ya8XB/vu9N1LEfMyVMhnCHobOKSg= ARC-Authentication-Results: i=1; imf08.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=YZb3M3pK; dmarc=pass (policy=quarantine) header.from=kernel.org; spf=pass (imf08.hostedemail.com: domain of sj@kernel.org designates 147.75.193.91 as permitted sender) smtp.mailfrom=sj@kernel.org Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by nyc.source.kernel.org (Postfix) with ESMTP id 491BBA400C1; Wed, 15 Jan 2025 04:16:07 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id DD822C4CEDF; Wed, 15 Jan 2025 04:17:54 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1736914675; bh=VsGwP/4rOYom0WXxctWyeqgUSyZah+lbhg84YI+77p0=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=YZb3M3pKw5po6kcZ1vOVbN662UprBLe/VB38YXQkzop5+7zCSP8PzF5ClSKYSCI1C ws/eZiZPaH5jHopPNgxGoRDM6YBs1wWmm9kOS/Tx4RsygQhf33nIMrqi9QWy8YEIVL 9KzxRVkEmAviwOgNpmog68MQku9mI192z0GWnlJdvmWjZMQuHLoxhLGZ9hyoDacaUF rKN45KIHzYEMwVepGQNTlAOFyblcXHyoxIc9efnE/mXfhXWTN9q8yXt6+yuwb48p4k CifQbTeeMff2GyTsOmYpU5dt5X+O4RiRyfuba3xVzUO6KmZZURN7NTfA/SvIGRJ27K ThSUkVLUbsVSA== From: SeongJae Park To: "Liam R. Howlett" Cc: SeongJae Park , Shakeel Butt , David Hildenbrand , Lorenzo Stoakes , Vlastimil Babka , Andrew Morton , Jens Axboe , Pavel Begunkov , damon@lists.linux.dev, io-uring@vger.kernel.org, linux-kernel@vger.kernel.org, linux-mm@kvack.org Subject: Re: [RFC PATCH] mm/madvise: remove redundant mmap_lock operations from process_madvise() Date: Tue, 14 Jan 2025 20:17:50 -0800 Message-Id: <20250115041750.58164-1-sj@kernel.org> X-Mailer: git-send-email 2.39.5 In-Reply-To: References: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Stat-Signature: to4jtcnrk7s7pcn67yz5ury3so9wc9ww X-Rspamd-Queue-Id: 2323516000F X-Rspam-User: X-Rspamd-Server: rspam01 X-HE-Tag: 1736914675-244069 X-HE-Meta: U2FsdGVkX18GWy7Z6iefhHVYHH1iSa96CuBsIkCj2/PcWfzXD/iLpKow00Vm2Lxzzb1Q/bxgi/nSPk76ZkOE2dqKzM6/GecByMxFT4ioLxXTts6eXqPQCIRSEzjrTr8Ahif1IeWRBXpxzawDMUj6OZOcqZ/ljKQ5pCxix08PKVsv7xwpvRoG5ej34dQptRstsGnP/dj4/IaFYBdQ3InfW+bMpegWjr8DQWqCfatfAE8KCp6BXL7WGvM4cA0LF/piadhFkNusR013J7I3rsz47ppODw6fXjqZrnbeRkhrTJgeRwh8bRFUbxnOUthubI0XXqjX6FsKwS3mNFQ4x6C3CDLEHYD9t2jt07TX+NQKz0MkQm4H/Io8AIvZx6T2L+SVm14+ykkjIgq3PW2OUXUrXUgd0e3cVNPLP+RJsiRb28jpNKKvaNs+Ix9IAW6gskz6HT6Ka8XOcIw9Vr+8tQk9yA6gYJtrSPSnw7hRmQDhusV4PlyTlaLTMxMBoQMXmtX8jT90UUd+ZF1fAaDOHX38eyo76PL5ES2F6H6sPgw4GOPQQpa8UfDSjqVIt8N2NXgTo9sSKYOn60C+lr5GdUoRFSuiQG+L8iCrHhc/IKVLHHCp8G6axmgm61hbAOv2N+nba0bIMysjIyuR5wZ9h8xTWebm4hsoZAeHeEJS5cIVXgDymoRrI9Xu8/RlRHJG9nbwZgEW0Zks/x+WeKxSMLFc5avkLwHeSrP+xgKHnfF3DpvFc5o5Ndhl3SZxVwL7xKgYNlaO96udkbLoHhQD/sPrk4fPMvKBPvcbTUTHrEM4Q2RBUzwXibC1Kg8X/IkyUyXaoEQJC8zUiORtJ8jiherCJ1ZECn/4uiGP0L9dXYDY9Vc5uUsadsSSxc7ZLaXYDTD5jv5Nj4V5KYDMndp87TZp8ER1zrnpxCe7FFRZCgdh1HoAllhPGZUqNvGO1Dnb2kDQff2kQM2NJhE03ezn9nz d50Ug2wS E9X2Qqn+gtC38NV9GA/RC5qnq+KQt4dEY+ImfYrZjPx3Wqb8613RfsmZy1gWsBmgOOPxgkZh46dwr4Mb/RaQoOGdHW4n4waOVo+R43mjjqZXO4dvuzUKFVh6vZCKOMqikvFLWi31Iy+y5hgYcnU3M8gTdf/ZT3205tuwuWoOOftEbZKTA1d/GIHQ3R22Y2EYtgHreot/VwCv4BX7Ed1mvK56WMVTE4XOvGpot6AXwQ3bjW/WUCu1AAB8Q4dqCOS4y/jAXnPKGtMk8wu3zVsYqjy8lZXH4OdCAuwjcTosyCsbhVzZz9ynwsik8ksVbm/zSlGBwAHXzgpPx3PrVW9/gYtn4WUYYjej43FbMLUqVrfarIvKjHIJksCUrspMUNjkgTPq6aFdmOnkbugzBkM16mCXGBQ== 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 Tue, 14 Jan 2025 22:44:53 -0500 "Liam R. Howlett" wrote: > * Shakeel Butt [250114 13:14]: > > Ccing relevant folks. > > Thanks Shakeel. > > > > > On Fri, Jan 10, 2025 at 04:46:18PM -0800, 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. > > > > > > Evaluation > > > ========== > > > > > > I measured the time to apply MADV_DONTNEED advice to 256 MiB memory > > > using multiple madvise() calls, 4 KiB per each call. I also do the same > > > with process_madvise(), but with varying iovec size from 1 to 1024. > > > The source code for the measurement is available at GitHub[1]. > > > > > > The measurement results are as below. 'sz_batches' column shows the > > > iovec size of process_madvise() calls. '0' is for madvise() calls case. > > > 'before' and 'after' columns are the measured time to apply > > > MADV_DONTNEED to the 256 MiB memory buffer in nanoseconds, on kernels > > > that built without and with this patch, respectively. So lower value > > > means better efficiency. 'after/before' column is the ratio of 'after' > > > to 'before'. > > > > > > sz_batches before after after/before > > > 0 124062365 96670188 0.779206393494111 > > > 1 136341258 113915688 0.835518827323714 > > > 2 105314942 78898211 0.749164453796119 > > > 4 82012858 59778998 0.728897875989153 > > > 8 82562651 51003069 0.617749895167489 > > > 16 71474930 47575960 0.665631431888076 > > > 32 71391211 42902076 0.600943385033768 > > > 64 68225932 41337835 0.605896230190011 > > > 128 71053578 42467240 0.597679120395598 > > > 256 85094126 41630463 0.489228398679364 > > > 512 68531628 44049763 0.6427654542221 > > > 1024 79338892 43370866 0.546653285755491 > > > > > > The measurement shows this patch reduces the process_madvise() latency, > > > proportional to the batching size, from about 25% with the batch size 2 > > > to about 55% with the batch size 1,024. The trend is somewhat we can > > > expect. > > > > > > Interestingly, this patch has also optimize madvise() and single batch > > > size process_madvise(), though. I ran this test multiple times, but the > > > results are consistent. I'm still investigating if there are something > > > I'm missing. But I believe the investigation may not necessarily be a > > > blocker of this RFC, so just posting this. I will add updates of the > > > madvise() and single batch size process_madvise() investigation later. > > > > > > [1] https://github.com/sjp38/eval_proc_madvise > > > > > > Signed-off-by: SeongJae Park > > > --- > > > 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); > > We are dropping externs when it is not needed as things are changed. Good point. I will drop it if I result in changing something here in next versions. > > Also, please don't use a flags for this. It will have a single user of > true, probably ever. Ok, that sounds fair. > > It might be better to break do_madvise up into more parts: > 1. is_madvise_valid(), which does the checking. > 2. madivse_do_behavior() > > The locking type is already extracted to madivse_need_mmap_write(). > > What do you think? Sounds good to me :) I will make the v2 of this patch following your suggestion after waiting for any possible more comments a bit. Thanks, SJ [...]