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 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 53CD8C43461 for ; Thu, 17 Sep 2020 19:42:34 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id A6F1621D92 for ; Thu, 17 Sep 2020 19:42:33 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=linux-foundation.org header.i=@linux-foundation.org header.b="D+14RVM0" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org A6F1621D92 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 EFE5F6B0037; Thu, 17 Sep 2020 15:42:32 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id EAED16B0055; Thu, 17 Sep 2020 15:42:32 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id DEBE66B005A; Thu, 17 Sep 2020 15:42:32 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0178.hostedemail.com [216.40.44.178]) by kanga.kvack.org (Postfix) with ESMTP id CA5306B0037 for ; Thu, 17 Sep 2020 15:42:32 -0400 (EDT) Received: from smtpin19.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay03.hostedemail.com (Postfix) with ESMTP id 866EE8249980 for ; Thu, 17 Sep 2020 19:42:32 +0000 (UTC) X-FDA: 77273575344.19.yard06_2c0926c27125 Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin19.hostedemail.com (Postfix) with ESMTP id 5A2C61AD1B2 for ; Thu, 17 Sep 2020 19:42:32 +0000 (UTC) X-HE-Tag: yard06_2c0926c27125 X-Filterd-Recvd-Size: 6113 Received: from mail-lj1-f195.google.com (mail-lj1-f195.google.com [209.85.208.195]) by imf01.hostedemail.com (Postfix) with ESMTP for ; Thu, 17 Sep 2020 19:42:31 +0000 (UTC) Received: by mail-lj1-f195.google.com with SMTP id y4so3057449ljk.8 for ; Thu, 17 Sep 2020 12:42:31 -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=UxLIUHpb7xnWpU+m8IJS8VPZyzTWrFzKBqPCi9w1E2E=; b=D+14RVM0zPR8KrtBKFfH8B2x8b6Il9d8XMhdSNjcwtF6tW3YeoUcL9+8DydvwdOiS1 pRfORF8k6PDjOF3f514UfZ6tX2NeuVFm4MbpcBj0HjzmK+IsnCqEG6U3oqJmff17FwYu vRTazCWJ7A3boom0FDbmYeTOc2PDTPCHDjXAk= 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=UxLIUHpb7xnWpU+m8IJS8VPZyzTWrFzKBqPCi9w1E2E=; b=nUoViX2xOwYlgDdqBd02+pztdfD4LqE1f3wVrs83mkLDijrHlSl8zVxgXPqo5jyj2s pkM+emGzldWsZe1FHzTL0O0twHAcKUdhqtETPNV8OhHLNcA7mRIhqgqTGfk/zSeqNjaN NoCRaI1RzdNvFqW90GWKkeEbxJpfkqYayhBVu6ga1GRazn0qxeYBsjPCuEMCZrwGyrhu Dhgw12eS8d75583xg9O1OGfZxWF59hEguJmUsmorUQU4zSRMb9sLD0VWQbjVUnKYvjCf 9/jcrguaPYGnVOD0L6S51o9iKnjKFvSicy7DLsMNI7kGH/RxO35pvg9+Nqt2+UCahLPh OxXg== X-Gm-Message-State: AOAM5304tsH086t2kBaA/0Iub2x8tuSd+8olw0hYwF4S2Fz0Ckhxa2Da h8/OvMQP6IHBimZngbbUmozxomfYPJ43Vw== X-Google-Smtp-Source: ABdhPJzISStYSzO47CWEdQywzZYB+TGWWP0Ha06bWDf7r+wP2flwcwyKHQc2SxOrp18KB0inmLGMXw== X-Received: by 2002:a2e:760e:: with SMTP id r14mr9865479ljc.331.1600371749641; Thu, 17 Sep 2020 12:42:29 -0700 (PDT) Received: from mail-lj1-f179.google.com (mail-lj1-f179.google.com. [209.85.208.179]) by smtp.gmail.com with ESMTPSA id h124sm95513lfd.203.2020.09.17.12.42.27 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 17 Sep 2020 12:42:28 -0700 (PDT) Received: by mail-lj1-f179.google.com with SMTP id n25so3082267ljj.4 for ; Thu, 17 Sep 2020 12:42:27 -0700 (PDT) X-Received: by 2002:a2e:7819:: with SMTP id t25mr10057301ljc.371.1600371747357; Thu, 17 Sep 2020 12:42:27 -0700 (PDT) MIME-Version: 1.0 References: <20200915191346.GD2949@xz-x1> <20200915193838.GN1221970@ziepe.ca> <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> In-Reply-To: <20200917190332.GB133226@xz-x1> From: Linus Torvalds Date: Thu, 17 Sep 2020 12:42:11 -0700 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH 1/4] mm: Trial do_wp_page() simplification To: Peter Xu Cc: Jason Gunthorpe , 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 12:03 PM Peter Xu wrote: > > The fork() should be slightly slower though, since we'll need to copy the data > for all the DMA buffers for each of the child processes, even if we should be > pretty sure those processes won't use these pages at all. I think that as long as we only trigger for pinned pages then that's fine - and in fact I think we might want to add a WARN_ON_ONCE() or something to it if we are sure enough about that page pinning. Because the whole "do page pinning without MADV_DONTFORK and then fork the area" is I feel a very very invalid load. It sure as hell isn't something we should care about performance for, and in fact it is something we should very well warn for exactly to let people know "this process is doing bad things". My main worry is that page_maybe_dma_pinned() not being exact. I'm not entirely convinced whether it really is extremely rare or not. I could well imagine some very fork-happy load having very elevated page counts (exactly *because* it is fork-happy), and then the performance thing might in fact be an issue. That said, you really have to be *very* fork-happy for this to trigger, with GUP_PIN_COUNTING_BIAS being 1024. Those kinds of fork-happy loads very much used to exist, but I think anybody who cares about performance will have long long since switched to threading, not forking. Do people fork a thousand children? Sure. Is it something we need to worry about a lot? I don't know. I'm thinking ot the android zygote disaster.. Is there possibly somethign else we can filter on than just GUP_PIN_COUNTING_BIAS? Because it could be as simple as just marking the vma itself and saying "this vma has had a page pinning event done on it". Because if we only start copying the page *iff* the vma is marked by that "this vma had page pinning" _and_ the page count is bigger than GUP_PIN_COUNTING_BIAS, than I think we can rest pretty easily knowing that we aren't going to hit some regular old-fashioned UNIX server cases with a lot of forks.. Linus