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 E1982C433E2 for ; Tue, 15 Sep 2020 00:19:24 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 6BF14208DB for ; Tue, 15 Sep 2020 00:19:24 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=linux-foundation.org header.i=@linux-foundation.org header.b="C1z9mpPd" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 6BF14208DB 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 79FEE6B0088; Mon, 14 Sep 2020 20:19:23 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 750AE6B0089; Mon, 14 Sep 2020 20:19:23 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 6176C6B008A; Mon, 14 Sep 2020 20:19:23 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0182.hostedemail.com [216.40.44.182]) by kanga.kvack.org (Postfix) with ESMTP id 47AA76B0088 for ; Mon, 14 Sep 2020 20:19:23 -0400 (EDT) Received: from smtpin18.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay03.hostedemail.com (Postfix) with ESMTP id 01EF78249980 for ; Tue, 15 Sep 2020 00:19:23 +0000 (UTC) X-FDA: 77263386606.18.sleep13_18108982710c Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin18.hostedemail.com (Postfix) with ESMTP id C3854100ED0CD for ; Tue, 15 Sep 2020 00:19:22 +0000 (UTC) X-HE-Tag: sleep13_18108982710c X-Filterd-Recvd-Size: 6023 Received: from mail-lj1-f194.google.com (mail-lj1-f194.google.com [209.85.208.194]) by imf48.hostedemail.com (Postfix) with ESMTP for ; Tue, 15 Sep 2020 00:19:22 +0000 (UTC) Received: by mail-lj1-f194.google.com with SMTP id s205so1212901lja.7 for ; Mon, 14 Sep 2020 17:19:22 -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=NZ/X7Z1ojnGM1c/SapOK8GvcEU91nHo1ce5yJcGFuqE=; b=C1z9mpPdVuT7rcGZrLZVAaF2cq1LYNf/HFVhxP5utJEBX3TwILpnb8fWI3/bprzx9B a8Ku50zNIR/rB9Pym36a4xwgWcV9TuJAxI9292KLBbdvcFjc5bI95VjT+gjB3G8nSOOV lW4/QVnW97B9Kh8PAFpB06DAaPV3Tb0L/8nr8= 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=NZ/X7Z1ojnGM1c/SapOK8GvcEU91nHo1ce5yJcGFuqE=; b=VJ5c9lED2DfKCpB8tXU/95bBGREwfZOw8aWL57v9N3DDAdmYQLuar5n/39OSrT1TmO +7oFashWpulbt9w+NUPD3zKpGRn4IRdgxCCa/ztbWjpXqHZdw8W6kbou5OMBhl6xffN6 RwfGEn72PDRdwGDDa5P1gGidC/gkbiZYx6asoUzrduoDtuNw5aPUpCPLIkGJRmgqUguy qkDz9i5dVczbvI1cYJNIaAHd/V0whzP7yCZLBjGRxdliu4BxkHY66XWq0h5iusaU7VGy T10914soXovukSqC+UYQaGTDTsnGtklG2+gEjmpFV9nNvEukSc0nAo3NvmWcVXehJGGj +3eA== X-Gm-Message-State: AOAM533H1de/pEZgCGrxL3yp3dWAhtg4qmcf/Y/oLJUUPm4OPPZng2VO Qq2o96F/5bBv041Jg3dt9ucCJFcSms0tHw== X-Google-Smtp-Source: ABdhPJxG9IhEucWMY6Dr+npL+An+OuGJwiNNyG6LNTODg3RnGJ2qOYbOV/X7It6+WX+7DKceVtei9w== X-Received: by 2002:a2e:7e10:: with SMTP id z16mr5971510ljc.439.1600129159993; Mon, 14 Sep 2020 17:19:19 -0700 (PDT) Received: from mail-lj1-f181.google.com (mail-lj1-f181.google.com. [209.85.208.181]) by smtp.gmail.com with ESMTPSA id a14sm3637928lfi.136.2020.09.14.17.19.18 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 14 Sep 2020 17:19:19 -0700 (PDT) Received: by mail-lj1-f181.google.com with SMTP id u21so1218529ljl.6 for ; Mon, 14 Sep 2020 17:19:18 -0700 (PDT) X-Received: by 2002:a2e:84d6:: with SMTP id q22mr5387477ljh.70.1600129158238; Mon, 14 Sep 2020 17:19:18 -0700 (PDT) MIME-Version: 1.0 References: <20200821234958.7896-1-peterx@redhat.com> <20200821234958.7896-2-peterx@redhat.com> <20200914143829.GA1424636@nvidia.com> <20200914183436.GD30881@xz-x1> <20200914211515.GA5901@xz-x1> <20200914225542.GO904879@nvidia.com> <20200914232851.GH1221970@ziepe.ca> In-Reply-To: <20200914232851.GH1221970@ziepe.ca> From: Linus Torvalds Date: Mon, 14 Sep 2020 17:19:02 -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 , 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-Rspamd-Queue-Id: C3854100ED0CD X-Spamd-Result: default: False [0.00 / 100.00] X-Rspamd-Server: rspam02 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 Mon, Sep 14, 2020 at 4:28 PM Jason Gunthorpe wrote: > > Hmm. If symptoms stop with this patch should we investigate > MADV_DONTFORK? I took a quick look at it, and it all looks trivially correct. All MADV_DONTFORK does is to set the VM_DONTCOPY flag in the vma. And dup_mmap() in kernel/fork.c is very trivial, and does if (mpnt->vm_flags & VM_DONTCOPY) { vm_stat_account(mm, mpnt->vm_flags, -vma_pages(mpnt)); continue; } for a vma that has that VM_DONTCOPY flag. So I don't think it's MADV_DONTFORK, and in fact if that _had_ been broken, then the old "look at page_mapcount()" would have shown the problem too, since by definition a fork() would have increased that count. That said, the thing Hugh worried about was random other VM-internal reasons why the page flags end up being elevated, that aren't due to these things. And he's right. The new aggressive COW by that do_wp_page() simplification will basically COW for any random thing. My argument to Hugh was that if the page has become private to a single mapping, even if it has its count elevated it should all simply be writable, ie it shouldn't have gotten the paeg fault that causes the COW in the first place. IOW, my thinking was that any proper page pinning will also have to make sure that the page is already writable and dirty, so no amount of other page counts should even matter. But that argument may be entirely bogus, because I didn't think of case "insert random case here". My original force-COW patch for GUP avoided this issue, exactly because it basically said that a GUP is a write - so it didn't care about whatever state the page had, it *forced* the page to be mapped dirty and writable in the target. But part of the argument for the do_wp_page() simplification thing was that it allowed us to remove my force-COW thing. Is there perhaps some easy test-case that shows this that doesn't require any actual rdma hardware? Linus