[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <YJvLYmEunXKNHMdX@t490s>
Date: Wed, 12 May 2021 08:34:42 -0400
From: Peter Xu <peterx@...hat.com>
To: Geert Uytterhoeven <geert@...ux-m68k.org>
Cc: Andrea Arcangeli <aarcange@...hat.com>,
Linux MM <linux-mm@...ck.org>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
Jan Kara <jack@...e.cz>, John Hubbard <jhubbard@...dia.com>,
Linus Torvalds <torvalds@...ux-foundation.org>,
Michal Hocko <mhocko@...e.com>,
Kirill Tkhai <ktkhai@...tuozzo.com>,
Kirill Shutemov <kirill@...temov.name>,
Oleg Nesterov <oleg@...hat.com>,
Andrew Morton <akpm@...ux-foundation.org>,
Jann Horn <jannh@...gle.com>, Jason Gunthorpe <jgg@...dia.com>,
Matthew Wilcox <willy@...radead.org>,
Hugh Dickins <hughd@...gle.com>
Subject: Re: [PATCH v2 3/3] mm: gup: pack has_pinned in MMF_HAS_PINNED
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@...hat.com> wrote:
> > From: Andrea Arcangeli <aarcange@...hat.com>
> >
> > 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@...hat.com>
> > [peterx: Fix build for task_mmu.c, introduce mm_set_has_pinned_flag, fix
> > comment here and there]
> > Signed-off-by: Peter Xu <peterx@...hat.com>
>
> 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(¤t->mm->has_pinned))
> > - atomic_set(¤t->mm->has_pinned, 1);
> > + if (gup_flags & FOLL_PIN)
> > + mm_set_has_pinned_flag(¤t->mm->flags);
>
> noreply@...erman.id.au 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@linux-foundation.org/
I'll remember to reply to the thread next time. Sorry for that!
--
Peter Xu
Powered by blists - more mailing lists