[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1457e171-17d0-7e1c-1526-10643ca76399@huawei.com>
Date: Tue, 10 Dec 2024 09:21:26 +0800
From: Jinjie Ruan <ruanjinjie@...wei.com>
To: Lorenzo Stoakes <lorenzo.stoakes@...cle.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 2024/12/9 21:42, Lorenzo Stoakes wrote:
> 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.
Sure, fix the bugs is a more urgent problem.
Thanks!
>
> Thanks!
>
>
> [0]:https://lore.kernel.org/linux-mm/aa2c1930-becc-4bc5-adfb-96e88290acc7@lucifer.local/
>
Powered by blists - more mailing lists