From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-3.9 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id A0C7EC43464 for ; Thu, 17 Sep 2020 20:36:18 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id EDE9F20838 for ; Thu, 17 Sep 2020 20:36:17 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=linux-foundation.org header.i=@linux-foundation.org header.b="Gw4YF1Eo" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org EDE9F20838 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=linux-foundation.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 572E16B0003; Thu, 17 Sep 2020 16:36:17 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 548666B0037; Thu, 17 Sep 2020 16:36:17 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 45FB78E0001; Thu, 17 Sep 2020 16:36:17 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0076.hostedemail.com [216.40.44.76]) by kanga.kvack.org (Postfix) with ESMTP id 30D5F6B0003 for ; Thu, 17 Sep 2020 16:36:17 -0400 (EDT) Received: from smtpin26.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay04.hostedemail.com (Postfix) with ESMTP id E798D1DE0 for ; Thu, 17 Sep 2020 20:36:16 +0000 (UTC) X-FDA: 77273710752.26.thing35_200209227125 Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin26.hostedemail.com (Postfix) with ESMTP id BF5D91804B656 for ; Thu, 17 Sep 2020 20:36:16 +0000 (UTC) X-HE-Tag: thing35_200209227125 X-Filterd-Recvd-Size: 5512 Received: from mail-lj1-f195.google.com (mail-lj1-f195.google.com [209.85.208.195]) by imf12.hostedemail.com (Postfix) with ESMTP for ; Thu, 17 Sep 2020 20:36:16 +0000 (UTC) Received: by mail-lj1-f195.google.com with SMTP id w3so3191289ljo.5 for ; Thu, 17 Sep 2020 13:36:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux-foundation.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=RwZiLc6S8KRXpHX9Z3VeVt6Qzg9ortSMhRW1DWsmxfU=; b=Gw4YF1Eo+YJ8TgEJHuR+iXYu0AX9ZB/vRTZi5W6owfBh+Fzo/uWlGdJHJMsfQur04/ Z12gGwxut2GKxd4MZW/Z8FgdJkaUGpnh+akWrazKSRsVrmkIChvw5UjjR7WQqUy9/mBm kEVmmYqN1HhbreponBnTKCuEJjAtHoKKQ8kHQ= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=RwZiLc6S8KRXpHX9Z3VeVt6Qzg9ortSMhRW1DWsmxfU=; b=b4CaYyyJtqDeBzDUznavAXqbc19JYiUoNKiXaAGN9HiEmCcAtYpopmQtK+aiFNhj2k 475b0xbZjG6b4J6ju+rXuApY4ovcMZtjuXCLhwiWsM5RsyEMImA6/yKm1F4su9VzIpYr glZZKwPPfymCH4O7lOVuhWwsLwPqUMT0xZV2RxKwvxCKxOCsJuqKWpyIuQeKgfL7GfLn cNogOyBPCCgyCvaVn9X0IYz6xCRIAGlgVa1brVtxajljiyFOKjuwUJ9L9LFGJRuVFHml lZj1fR0xtd3KMtAayaJKZacz+AIVRD0abuHjDUO50o8+gfst+tL5INsuyHKTsGQJcz/1 nGQA== X-Gm-Message-State: AOAM530GGTN0/VtQ04o50LiphyRqolLYVmLpVkFQCWje3fekl1ywIIaB BnbmgfSrZdhnqLK70VK8DLCH93/ckosydA== X-Google-Smtp-Source: ABdhPJxUirD70MsCfC7VVcg5C/zoYwfBedb0H9mLmY8QpJxVUOSqDj7pNuSqiMG4DwgoGHql59HPcw== X-Received: by 2002:a2e:9dcb:: with SMTP id x11mr11253060ljj.450.1600374974216; Thu, 17 Sep 2020 13:36:14 -0700 (PDT) Received: from mail-lf1-f46.google.com (mail-lf1-f46.google.com. [209.85.167.46]) by smtp.gmail.com with ESMTPSA id 194sm128595lfo.104.2020.09.17.13.36.12 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 17 Sep 2020 13:36:13 -0700 (PDT) Received: by mail-lf1-f46.google.com with SMTP id y11so3649036lfl.5 for ; Thu, 17 Sep 2020 13:36:12 -0700 (PDT) X-Received: by 2002:ac2:4ec7:: with SMTP id p7mr8748891lfr.352.1600374972561; Thu, 17 Sep 2020 13:36:12 -0700 (PDT) MIME-Version: 1.0 References: <20200915213330.GE2949@xz-x1> <20200915232238.GO1221970@ziepe.ca> <20200916174804.GC8409@ziepe.ca> <20200916184619.GB40154@xz-x1> <20200917112538.GD8409@ziepe.ca> <20200917181411.GA133226@xz-x1> <20200917190332.GB133226@xz-x1> <20200917200638.GM8409@ziepe.ca> In-Reply-To: <20200917200638.GM8409@ziepe.ca> From: Linus Torvalds Date: Thu, 17 Sep 2020 13:35:56 -0700 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH 1/4] mm: Trial do_wp_page() simplification To: Jason Gunthorpe Cc: Peter Xu , John Hubbard , Leon Romanovsky , Linux-MM , Linux Kernel Mailing List , "Maya B . Gokhale" , Yang Shi , Marty Mcfadden , Kirill Shutemov , Oleg Nesterov , Jann Horn , Jan Kara , Kirill Tkhai , Andrea Arcangeli , Christoph Hellwig , Andrew Morton Content-Type: text/plain; charset="UTF-8" X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Thu, Sep 17, 2020 at 1:06 PM Jason Gunthorpe wrote: > > Given that this is a user visible regression, it is nearly rc6, what > do you prefer for next steps? Since I had to deal with the page lock performance regression too, and I think we have a fairly simple way forward, I'd rather do an rc8 and get this done with, than revert and know we have to deal with it anyway. Particularly since I think this would _finally_ make page pinning make sense. In it's current state, it's just yet another broken GUP that doesn't actually fix things. But if we have the semantics that page pinning really fixes things in the page tables, I think we now have a proper solution to this and a _much_ cleaner model for it. If it means that page pinning can also stop worrying about MADV_DONTFORK any more, that would be an added API bonus. For that to happen, we'd need to have the vma flag so that we wouldn't have any worry about non-pinners, but as you suggested, I think even just a mm-wide counter - or flag - to deal with the fast-bup case is likely perfectly sufficient. Yes, you'd still take a hit on fork, but only the actual process that did pinning would take that hit. And *if* that ends up being a big deal, the MADV_DONTFORK can be used to avoid it, rather than be a correctness issue. It really feels like this should be just "tens of lines of fairly simple code", and it would clarify our GUP/PIN/COW rules enormously. Linus