[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <f7f1b152-3f25-4df3-9589-2fceb6d18613@lucifer.local>
Date: Mon, 9 Dec 2024 13:42:41 +0000
From: Lorenzo Stoakes <lorenzo.stoakes@...cle.com>
To: Jinjie Ruan <ruanjinjie@...wei.com>
Cc: viro@...iv.linux.org.uk, brauner@...nel.org, jack@...e.cz,
akpm@...ux-foundation.org, Liam.Howlett@...cle.com,
lokeshgidra@...gle.com, rppt@...nel.org, aarcange@...hat.com,
Jason@...c4.com, linux-fsdevel@...r.kernel.org,
linux-kernel@...r.kernel.org, linux-mm@...ck.org
Subject: Re: [PATCH 0/2] userfaultfd: handle few NULL check inline
On Mon, Dec 09, 2024 at 09:25:47PM +0800, Jinjie Ruan wrote:
> Handle dup_userfaultfd() and anon_vma_fork() NULL check inline to
> save some function call overhead. The Unixbench single core process
> create has 1% improve with these patches.
>
> Jinjie Ruan (2):
> userfaultfd: handle dup_userfaultfd() NULL check inline
> mm, rmap: handle anon_vma_fork() NULL check inline
>
> fs/userfaultfd.c | 5 +----
> include/linux/rmap.h | 12 +++++++++++-
> include/linux/userfaultfd_k.h | 11 ++++++++++-
> mm/rmap.c | 6 +-----
> 4 files changed, 23 insertions(+), 11 deletions(-)
>
> --
> 2.34.1
>
Coincidentally I've just diagosed a rather nasty bug in this code [0], so
could we hold off on this change for just a little bit until we can get a
fix out for this please?
I'd rather not complicate anything until we're sure we won't need to change
this.
Thanks!
[0]:https://lore.kernel.org/linux-mm/aa2c1930-becc-4bc5-adfb-96e88290acc7@lucifer.local/
Powered by blists - more mailing lists