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 17A5AC02180 for ; Wed, 15 Jan 2025 06:19:17 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 8B882280005; Wed, 15 Jan 2025 01:19:16 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 86830280001; Wed, 15 Jan 2025 01:19:16 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 77E6E280005; Wed, 15 Jan 2025 01:19:16 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0017.hostedemail.com [216.40.44.17]) by kanga.kvack.org (Postfix) with ESMTP id 5A463280001 for ; Wed, 15 Jan 2025 01:19:16 -0500 (EST) Received: from smtpin05.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay07.hostedemail.com (Postfix) with ESMTP id 0A1DB16081D for ; Wed, 15 Jan 2025 06:19:16 +0000 (UTC) X-FDA: 83008683912.05.1E1A62C Received: from nyc.source.kernel.org (nyc.source.kernel.org [147.75.193.91]) by imf13.hostedemail.com (Postfix) with ESMTP id 6A1DE2000D for ; Wed, 15 Jan 2025 06:19:14 +0000 (UTC) Authentication-Results: imf13.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=KxHHGFKn; spf=pass (imf13.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=1736921954; 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=s5DwRdxfjdZJpSmpgZHsRJoj6sYy3eIqHAbagnj9rHA=; b=dAcnItMdtcPSBrKuyOMy5sOYK/Y/wH3v5mCcOAZgW5xJsNgu3GiTMYXy/1WECuTTmhWaT7 ULrpsQ6FcUE/ojVKQo0X+lPrOEzqXMwnNfRG5gIurk7ewBwdwYLuqZ87bvajYpix1mRNDZ FLEl5tLH4dQQBr1haIT2KdNHx/q6kjk= ARC-Authentication-Results: i=1; imf13.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=KxHHGFKn; spf=pass (imf13.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=1736921954; a=rsa-sha256; cv=none; b=LnOeykfKk7xASOwlkdIiYQO7sfAemuaaNy6W8Cmlfch050yyt0Z6FFrMubFrw8JwOn04be CqR0BgdeAEpkcISsaeWlkNiNbyodRMoUyhMNziRaU2gLnz/XM7J6sU30wxvJIqI+d2PD9N UT151/OI9zYLAe09VTNkoNDGFNpZ1E4= Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by nyc.source.kernel.org (Postfix) with ESMTP id 8B03DA414C5; Wed, 15 Jan 2025 06:17:25 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 2472CC4CEE1; Wed, 15 Jan 2025 06:19:13 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1736921953; bh=xPfKkMWgx5qIRi97DeQ/SvkD1AWZgJlDQc7lklyto6U=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=KxHHGFKnvjMQiiLrPU8h7trzS1ZSStbmsBPHnLXveVg0hGsj2Nus6RhFsIdofw2Y1 DCaB7M+gA5gWz7tYi0adr9fLRugGCd18LjhBHrWpQuSt+MwOkg4iJZvR8tJyJdiCAW knlbCo7Q3muot6CL6Ka18Ch6KlxGgk4td6SfY9AsNK5gMZlHNe1ybf2d5R8uY3VwwE 1JpC7BC19Xn6zdzBy3lFlrVpKnuPbKGVOihycCRPbMMf7VCy6C7LE+uzw9JDY00iDF t7ba3yPUIEiQtoXAqMoYwoghy/FivpU/vcdcQw7RUu6HsGt18T254ml3wO8fj8SS1O jSfMx/9nQvdRA== From: SeongJae Park To: Honggyu Kim Cc: SeongJae Park , 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 Subject: Re: [RFC PATCH] mm/madvise: remove redundant mmap_lock operations from process_madvise() Date: Tue, 14 Jan 2025 22:19:10 -0800 Message-Id: <20250115061910.58938-1-sj@kernel.org> X-Mailer: git-send-email 2.39.5 In-Reply-To: <00242654-5e98-4489-ae6d-f4dd01bfdaa7@sk.com> References: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Rspamd-Server: rspam06 X-Rspamd-Queue-Id: 6A1DE2000D X-Rspam-User: X-Stat-Signature: 6st3wozh9xabjqaczsb4tta4b3etxooz X-HE-Tag: 1736921954-250561 X-HE-Meta: U2FsdGVkX19pnekgqNTWZLC6RiC6YHc9WuPfdBgejPT1+44FJVTEJWHIPrlPDKFGu7t9LmDoAhnU0A1lRjlLJBNWp1a+e3Yz1AXRwNrzcn9sDnrdNQjIxrVAObIAUrKEhrQ4rprEYqpBQTaiSTsQ9pIckodsE2O8BXPHDSi1mwGtl1Afk6kThyDn8MQxY+Gp1E50OYDRqIisJyWR0UWz9DWCuoYUh40n4emcZ0Q94TNUDljWz8UN1dwU54k98m4PIWnmfyCcx9sE7UbpjDg5BVqfSz4FEOCRmGSC5z4AGgp38tGwGngWmkbNp9kn8Hy+1myFEf242uPQQBV7BPdHsJumz7DoB5pdonxKwrM/00x/vKGMkP6uuWHPg4p86I+G6BnrCk1YdTJ7HMtAzDjM1YdKeI/vluJvItA0Jq/QRIfVz+i/ldu6x5mx8+PV6gSg6eGTWCI84OCjy7IxtRTHsgy2ymJKuNTNsIFfl7CYfQMHkE7ikjgYbysyhBBZpiFt6UBIQbqvE04O6oNgx1v43NnM6wp+22HOyrzFt5Z5fTTrgocm1LXsNYwwnhTatJuHtOQZZKTE6pvDPe9II3Apf13An9U9wSxN3KSqOUcdk1EGcI/6momZdbtKeTnaWu0mJ8pEXJfRa7OihFeJU6Bh+k863EeQOC3i31ig2d3LagCok9QnQKje1fk4u/kJ4JQxaP7xTF8LEPrgQF3jvlls8u2No7C7ErKx8M9NZdzmf3DEpXHHcn5szzq88O65/L110I5CA8YP+4D/e9TcLwMN16qHsdXgdbzZPvGhiLFw5jetB0DaEsDyYCZKjof8N3RzOrrLg7IgN0lAXwakc15CMXP9kFhPd8S1iIbLsWx28SG2SEW1Cs0Ff0pP9UE7iMxl1G3oM/JjInNed3ZjiLes47tyDHO82dQKbfaz5sv034bOowvbGwxt3b9Fbk8JbYaPfnhSRMKah9R8OtQN6QI PqTvcYot yQiI61updVydLSsFz9PNn6b+RVcP/INulWBA8FB0rx5dpXBjn2ieTHDNEwUf5j0Hvw6SZcmVTyPvyU3qCBljoaSJJFFv+5PKK7alrg49yyHoum20NKezo4YcEDqZm7mg/Ur6cPzfuoy6swGI+HeHEbi+pybx67zxtIKTNJsyDSv/Xbw6a0HPJevvJtbDnOCE1+Ex9Myor6dnhu9ya6AmEhO1lpabljmIYHAciRWF+F8lFZKsR0Z8O3sl/67P22wkFBStznPIoSR2mgHVlAvpiphO8Ijm9n+avdUgkpFCxdBJrKhkEiomSWv78INxHhu5haseU2B5OUFrTb3OmtcfbQDRtWT6tdol6xMgqy5gzXLDh/0fl9lXdn4ALcvOz5nvD4w0a12JsMB9KvHBtpLC2pYsp5hDra3mcHDyp 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 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 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 Thanks, SJ [...]