Re: [PATCH v2 3/3] mm: gup: pack has_pinned in MMF_HAS_PINNED

[Peter Xu]

On Wed, May 12, 2021 at 11:49:05AM +0200, Geert Uytterhoeven wrote:
> Hi Peter, Andrea,

Hi, Geert, Naresh,

(Adding Naresh too since Naresh reported the same issue at the meantime)

> 
> On Fri, May 7, 2021 at 7:26 PM Peter Xu <peterx@xxxxxxxxxx> wrote:
> > From: Andrea Arcangeli <aarcange@xxxxxxxxxx>
> >
> > has_pinned 32bit can be packed in the MMF_HAS_PINNED bit as a noop
> > cleanup.
> >
> > Any atomic_inc/dec to the mm cacheline shared by all threads in
> > pin-fast would reintroduce a loss of SMP scalability to pin-fast, so
> > there's no future potential usefulness to keep an atomic in the mm for
> > this.
> >
> > set_bit(MMF_HAS_PINNED) will be theoretically a bit slower than
> > WRITE_ONCE (atomic_set is equivalent to WRITE_ONCE), but the set_bit
> > (just like atomic_set after this commit) has to be still issued only
> > once per "mm", so the difference between the two will be lost in the
> > noise.
> >
> > will-it-scale "mmap2" shows no change in performance with enterprise
> > config as expected.
> >
> > will-it-scale "pin_fast" retains the > 4000% SMP scalability
> > performance improvement against upstream as expected.
> >
> > This is a noop as far as overall performance and SMP scalability are
> > concerned.
> >
> > Signed-off-by: Andrea Arcangeli <aarcange@xxxxxxxxxx>
> > [peterx: Fix build for task_mmu.c, introduce mm_set_has_pinned_flag, fix
> >  comment here and there]
> > Signed-off-by: Peter Xu <peterx@xxxxxxxxxx>
> 
> Thanks for your patch, which is now in linux-next.
> 
> > diff --git a/mm/gup.c b/mm/gup.c
> > index 9933bc5c2eff2..bb130723a6717 100644
> > --- a/mm/gup.c
> > +++ b/mm/gup.c
> > @@ -1270,6 +1270,17 @@ int fixup_user_fault(struct mm_struct *mm,
> >  }
> >  EXPORT_SYMBOL_GPL(fixup_user_fault);
> >
> > +/*
> > + * Set the MMF_HAS_PINNED if not set yet; after set it'll be there for the mm's
> > + * lifecycle.  Avoid setting the bit unless necessary, or it might cause write
> > + * cache bouncing on large SMP machines for concurrent pinned gups.
> > + */
> > +static inline void mm_set_has_pinned_flag(unsigned long *mm_flags)
> > +{
> > +       if (!test_bit(MMF_HAS_PINNED, mm_flags))
> > +               set_bit(MMF_HAS_PINNED, mm_flags);
> > +}
> > +
> >  /*
> >   * Please note that this function, unlike __get_user_pages will not
> >   * return 0 for nr_pages > 0 without FOLL_NOWAIT
> > @@ -1292,8 +1303,8 @@ static __always_inline long __get_user_pages_locked(struct mm_struct *mm,
> >                 BUG_ON(*locked != 1);
> >         }
> >
> > -       if ((flags & FOLL_PIN) && !atomic_read(&mm->has_pinned))
> > -               atomic_set(&mm->has_pinned, 1);
> > +       if (flags & FOLL_PIN)
> > +               mm_set_has_pinned_flag(&mm->flags);
> >
> >         /*
> >          * FOLL_PIN and FOLL_GET are mutually exclusive. Traditional behavior
> > @@ -2617,8 +2628,8 @@ static int internal_get_user_pages_fast(unsigned long start,
> >                                        FOLL_FAST_ONLY)))
> >                 return -EINVAL;
> >
> > -       if ((gup_flags & FOLL_PIN) && !atomic_read(&current->mm->has_pinned))
> > -               atomic_set(&current->mm->has_pinned, 1);
> > +       if (gup_flags & FOLL_PIN)
> > +               mm_set_has_pinned_flag(&current->mm->flags);
> 
> noreply@xxxxxxxxxxxxxx reports:
> 
>     FAILED linux-next/m5272c3_defconfig/m68k-gcc8 Wed May 12, 19:30
>     http://kisskb.ellerman.id.au/kisskb/buildresult/14543658/
>     Commit:   Add linux-next specific files for 20210512
>           ec85c95b0c90a17413901b018e8ade7b9eae7cad
>     Compiler: m68k-linux-gcc (GCC) 8.1.0 / GNU ld (GNU Binutils) 2.30
> 
>     mm/gup.c:2698:3: error: implicit declaration of function
> 'mm_set_has_pinned_flag'; did you mean 'set_tsk_thread_flag'?
> [-Werror=implicit-function-declaration]
> 
> It's definition is inside the #ifdef CONFIG_MMU section, but the last
> user isn't.

Indeed that's wrong and I replied to the mm-commit email but not here to fix
this up yesterday:

https://lore.kernel.org/mm-commits/20210511220029.m6tGcxUIw%25akpm@xxxxxxxxxxxxxxxxxxxx/

I'll remember to reply to the thread next time. Sorry for that!

-- 
Peter Xu