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 42781C4741F for ; Mon, 28 Sep 2020 19:30:19 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 5D9BE2071E for ; Mon, 28 Sep 2020 19:30:18 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=linux-foundation.org header.i=@linux-foundation.org header.b="de4GMA4Q" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 5D9BE2071E 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 CE90C6B006E; Mon, 28 Sep 2020 15:30:17 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id C990C8E0001; Mon, 28 Sep 2020 15:30:17 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id B88306B0071; Mon, 28 Sep 2020 15:30:17 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0146.hostedemail.com [216.40.44.146]) by kanga.kvack.org (Postfix) with ESMTP id A2CA56B006E for ; Mon, 28 Sep 2020 15:30:17 -0400 (EDT) Received: from smtpin10.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay02.hostedemail.com (Postfix) with ESMTP id 5A55C3637 for ; Mon, 28 Sep 2020 19:30:17 +0000 (UTC) X-FDA: 77313461274.10.pipe00_0406d7a27184 Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin10.hostedemail.com (Postfix) with ESMTP id 3099316A044 for ; Mon, 28 Sep 2020 19:30:17 +0000 (UTC) X-HE-Tag: pipe00_0406d7a27184 X-Filterd-Recvd-Size: 6137 Received: from mail-lf1-f68.google.com (mail-lf1-f68.google.com [209.85.167.68]) by imf02.hostedemail.com (Postfix) with ESMTP for ; Mon, 28 Sep 2020 19:30:16 +0000 (UTC) Received: by mail-lf1-f68.google.com with SMTP id x69so2681413lff.3 for ; Mon, 28 Sep 2020 12:30:16 -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=wY4Gq79q0P/2bX+CuESc1n2E6IaS6wqp2Rm0+ZTB6Q0=; b=de4GMA4QpsyK1q3+qSjbj6c/bLM77xIl2+5sVk0F/tdoa8BfjO8UHtRwPAqhaCHHUk 3uuZoHZ6nnGsdkuYJCmNPv8mLzeOXJVMpSpnADjB0rjFW0XGsiRnswMvG/RD1vL90qBW 9kJvFSyX6yVkV/XpEYZh26BJn07eZw9TlrY9s= 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=wY4Gq79q0P/2bX+CuESc1n2E6IaS6wqp2Rm0+ZTB6Q0=; b=SCud5gVKfGZ+ooK11kHAtEN1rS/V6CBxsoI2jSP8tVDZJ6mzKyodHQdOJjkRh+yyVI hjxp30XP/9gLdhT4fJsKfziaUp7Kfijdso//NfyVxDqyefrweUMuUm8mC3hugLLb0tnW F9Nwih/RZT7lV+FlJDoxnAivcbvAmVaoxhkQzjpScqtWheWgg2loYk+UVCOrqU08PVfT YO5YTTfwrL9Qp/Dc22mgiT3Hmr+yh+Tr5nfMAs6dnwLn3XeHPGQicqBnD2Jc9SV4AHaS /vDHQ15qPaKMLdMVXYh1LmUz8N4s9vSCCENbgrrNgWQRdQRlBogxtWdF7OoX9lUuH7G6 l3zg== X-Gm-Message-State: AOAM5309MvLrh86smJscSDNm4ohsM7+Xxw3VbPVwb5agS9oihp3wiX4N 5KmfIh/8AUJGD+U3RLsp12VlfmB3pSrhGg== X-Google-Smtp-Source: ABdhPJyMPprl6qRqiOafWusEsbaOwzH5lkR+Qfex0f4LuUk5ey56OY4DWMaQW256fYyG6KYBDSGeEw== X-Received: by 2002:ac2:5f50:: with SMTP id 16mr1065209lfz.533.1601321414424; Mon, 28 Sep 2020 12:30:14 -0700 (PDT) Received: from mail-lf1-f49.google.com (mail-lf1-f49.google.com. [209.85.167.49]) by smtp.gmail.com with ESMTPSA id 138sm2946886lfl.241.2020.09.28.12.30.12 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 28 Sep 2020 12:30:13 -0700 (PDT) Received: by mail-lf1-f49.google.com with SMTP id b12so2648801lfp.9 for ; Mon, 28 Sep 2020 12:30:12 -0700 (PDT) X-Received: by 2002:ac2:4a6a:: with SMTP id q10mr899873lfp.534.1601321412324; Mon, 28 Sep 2020 12:30:12 -0700 (PDT) MIME-Version: 1.0 References: <20200926004136.GJ9916@ziepe.ca> <20200927062337.GE2280698@unreal> <20200928124937.GN9916@ziepe.ca> <20200928172256.GB59869@xz-x1> <20200928183928.GR9916@ziepe.ca> In-Reply-To: <20200928183928.GR9916@ziepe.ca> From: Linus Torvalds Date: Mon, 28 Sep 2020 12:29:55 -0700 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH 1/5] mm: Introduce mm_struct.has_pinned To: Jason Gunthorpe Cc: Peter Xu , Leon Romanovsky , John Hubbard , Linux-MM , Linux Kernel Mailing List , Andrew Morton , Jan Kara , Michal Hocko , Kirill Tkhai , Kirill Shutemov , Hugh Dickins , Christoph Hellwig , Andrea Arcangeli , Oleg Nesterov , Jann Horn 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 Mon, Sep 28, 2020 at 11:39 AM Jason Gunthorpe wrote: > > I prefer the version where read pin and write pin are symmetric. The > PTE in the MM should not change once pinned. The thing is, I don't really see how to do that. Right now the write pin fastpath part depends on the PTE being writable. That implies "this VM has access to this page". For a read pin there simply is no other way to do it. So we'd basically say "fast read pin only works on writable pages", and then we'd have to go to the slow path if it isn't dirty and writable. And the slow path would then do whatever COW is required, but it wouldn't mark the result dirty (and in the case of a shared mapping, couldn't mark it writable). So a read pin action would basically never work for the fast-path for a few cases, notably a shared read-only mapping - because we could never mark it in the page tables as "fast pin accessible" See the problem? A read-only pin is fundamentally different from a write one, because a write one has that fundamental mark of "I have private access to this page" in ways a read one simply does not. So we could make the requirement be that a pinned page is either (a) from a shared mapping (so the pinning depends on the page cache association). But we can't test this in the fast path. or (b) for a private mapping we require page_mapcount() == 1 and that it's writable. but since (a) requires the mapping type, we can't check in the fast path - we only have the PTE and the page. So the fast-path can only "emulate" it by that "writable", which is a proper subset of (a) or (b), but it's not something that is in any way guaranteed. End result: FOLL_PIN would really only work on private pages, and only if you don't want to share with the page cache. And it would basically have no advantages over a writable FOLL_PIN. It would break the association with any backing store for private pages, because otherwise it can't follow future writes. Linus