On Wed, Jul 17, 2024 at 2:36 AM Yu Zhao <yuzhao@xxxxxxxxxx> wrote:
>
> Hi Janosch and Oliver,
>
> On Wed, Jul 17, 2024 at 1:57 AM Janosch Frank <frankja@xxxxxxxxxxxxx> wrote:
> >
> > On 7/9/24 07:11, kernel test robot wrote:
> > > Hello,
> > >
> > > kernel test robot noticed a -34.3% regression of vm-scalability.throughput on:
> > >
> > >
> > > commit: 875fa64577da9bc8e9963ee14fef8433f20653e7 ("mm/hugetlb_vmemmap: fix race with speculative PFN walkers")
> > > https://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git master
> > >
> > > [still regression on linux-next/master 0b58e108042b0ed28a71cd7edf5175999955b233]
> > >
> > This has hit s390 huge page backed KVM guests as well.
> > Our simple start/stop test case went from ~5 to over 50 seconds of runtime.
>
> Could you try the attached patch please? Thank you.
Thanks, Yosry, for spotting the following typo:
flags &= VMEMMAP_SYNCHRONIZE_RCU;
It's supposed to be:
flags &= ~VMEMMAP_SYNCHRONIZE_RCU;
Reattaching v2 with the above typo fixed. Please let me know, Janosch & Oliver.
Attachment:
hugetlb-fix-v2.patch
Description: Binary data
