Received: by 2002:a05:6a10:206:0:0:0:0 with SMTP id 6csp4441777pxj; Wed, 12 May 2021 05:52:58 -0700 (PDT) X-Google-Smtp-Source: ABdhPJyBmaAZjiNV5W4x7Ejn+37H1Lzpf16SPBvGrDw141YnfUh7RYAqOKYbDRjEGOsqqufhjAGc X-Received: by 2002:a05:6402:44:: with SMTP id f4mr26578426edu.364.1620823977892; Wed, 12 May 2021 05:52:57 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1620823977; cv=none; d=google.com; s=arc-20160816; b=uR0RNVv5weUa58KrIYPjVGYHD+PBPLKFouXvDTSSuxj6HmZH/GRraV3/cfV4M3C3jW rodkeFlCiCzCyctdAtja4OtJqCpHDcJ+VxfwwE8TrfGWIcdGkmuZLhWww5aVgDDwb0tC r8uSKR2BhFG1X7NHNJmX77tzsZToIyTEu0PskKK0Zzbz8urcXVPee2v5gEkR3vB1dj/u t1tOpTnda+sxM5zL5d188UdWESvR6A03gfOMz5l8jr0P/KBKgtbgmk0NYD+kAYiD9Fhm JeHOmPthI/1/bHf59oTxEX3fZV/8wQcRQtekh1vDQuaKds1HHXiz/+czbZJ/en/M9AN+ 0szQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-disposition:mime-version :references:message-id:subject:cc:to:from:date:dkim-signature; bh=plE+nL+ct6AZIIPoxz1my01jPeDymgnbPjG0iiRllwM=; b=SAfg6qA3ieum77oq5QLP/4vSHfaCpc/GIa/3/Exy6L42gsFmBpL0bLX0SzFySEpVW3 w923kp6eW3pvOUo+9/V6EZImwrVi48OkUmh2QMytEYSBAvz3CV283FXC3cqIKhq0DLrX JBbu3lpBiHffljCsKT5Ijsqg20xLazLqNUVZfS+EuTqy6pUUZx9ZgfPyiOA1PddDdMWI /zmY+SjjLNXLe1X7HUFs0/LGk77+sy11qQLSaEMSZxE5RBH14AgsqYddhpm8DSMcB9RR KN+KGVX5+sjtDJ24qFGSxl6CMaygdFU17oDMgdzDWL1rG41PicYVLtNSNbbCfDkEvEDH wAMw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=eLkDWng3; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id g16si670100ejr.663.2021.05.12.05.52.25; Wed, 12 May 2021 05:52:57 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=eLkDWng3; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232565AbhELMf6 (ORCPT + 99 others); Wed, 12 May 2021 08:35:58 -0400 Received: from us-smtp-delivery-124.mimecast.com ([216.205.24.124]:20623 "EHLO us-smtp-delivery-124.mimecast.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232493AbhELMf5 (ORCPT ); Wed, 12 May 2021 08:35:57 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1620822889; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=plE+nL+ct6AZIIPoxz1my01jPeDymgnbPjG0iiRllwM=; b=eLkDWng3XltHm+v/4dek193edElz1kauXcwMAe27S25Q4hdnRPsWQrW/OZv+X8jQyE2zwz KnMUSCE0+W8OMC3PiC35kaOO5+EYRCova8GlVJDAzb2srF9PM4isknrOZRP5WpdLcakjwa cXt7/hyVcaJheyG4DXUGj1OHa4eC9B4= Received: from mail-qk1-f200.google.com (mail-qk1-f200.google.com [209.85.222.200]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-379-YfBkDSxPOPq6jWv4bzNZMA-1; Wed, 12 May 2021 08:34:47 -0400 X-MC-Unique: YfBkDSxPOPq6jWv4bzNZMA-1 Received: by mail-qk1-f200.google.com with SMTP id 4-20020a370d040000b02902fa09aa4ad4so8676988qkn.11 for ; Wed, 12 May 2021 05:34:47 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=plE+nL+ct6AZIIPoxz1my01jPeDymgnbPjG0iiRllwM=; b=Ycrp9hWCV+tznITQdt2zbin/ZxL516uobnTalBZ9uJE5z6BnvxtHyrp66srlccxxD8 fD/YrOV99ijqUSsP+4uhjktNja0ddnbjl3RpEM+zdYWtc9lz+y3N5Yk3S8t0XTeBG2Hm Az64kLVi+zjasxohMtsTDg7n3CAJbadsK8xDpGiA3f7qpiu/CF+RVQ566G1QXZIFWgBx 2UVu4Ct2wfFcqOvX5RtBUV/Kzf1sf1ul8TyTpt3OK98yt+WnJTU4v9hgy6J0Z1VzbOC+ zTZE0CIe4LCZFU+qkLe6EDOVcP6A6COLRxQ6+tkNWPhdvW0KNFIZSinS96JPG3nFO1M4 NzBg== X-Gm-Message-State: AOAM532O/yaTj9cUKHGkxcZqCVkm4WRl/W6x6ZMBV/+k4X8VkG+tZXHU CEFzHq3Dg8JfORhBlnEGGF1PFMEKA6CzYP9Q46ilcPwT4Yoeo4VbFqLQQ4yyU3/bHEQBJw/SNUe HxSVqHON6UjuDztB+iNXsdM2N X-Received: by 2002:a05:622a:341:: with SMTP id r1mr4583017qtw.307.1620822885103; Wed, 12 May 2021 05:34:45 -0700 (PDT) X-Received: by 2002:a05:622a:341:: with SMTP id r1mr4582983qtw.307.1620822884723; Wed, 12 May 2021 05:34:44 -0700 (PDT) Received: from t490s (bras-base-toroon474qw-grc-72-184-145-4-219.dsl.bell.ca. [184.145.4.219]) by smtp.gmail.com with ESMTPSA id o189sm15923330qkd.60.2021.05.12.05.34.43 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 12 May 2021 05:34:44 -0700 (PDT) Date: Wed, 12 May 2021 08:34:42 -0400 From: Peter Xu To: Geert Uytterhoeven Cc: Andrea Arcangeli , Linux MM , Linux Kernel Mailing List , Jan Kara , John Hubbard , Linus Torvalds , Michal Hocko , Kirill Tkhai , Kirill Shutemov , Oleg Nesterov , Andrew Morton , Jann Horn , Jason Gunthorpe , Matthew Wilcox , Hugh Dickins Subject: Re: [PATCH v2 3/3] mm: gup: pack has_pinned in MMF_HAS_PINNED Message-ID: References: <20210507150553.208763-1-peterx@redhat.com> <20210507150553.208763-4-peterx@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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 wrote: > > From: Andrea Arcangeli > > > > 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 > > [peterx: Fix build for task_mmu.c, introduce mm_set_has_pinned_flag, fix > > comment here and there] > > Signed-off-by: Peter Xu > > 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@ellerman.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