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=-6.1 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, 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 00920C47082 for ; Thu, 3 Jun 2021 14:51:30 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id ABB03613E7 for ; Thu, 3 Jun 2021 14:51:29 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org ABB03613E7 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=redhat.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id EC0246B00C2; Thu, 3 Jun 2021 10:51:28 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id E5CE76B00C3; Thu, 3 Jun 2021 10:51:28 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id CAF446B00C4; Thu, 3 Jun 2021 10:51:28 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0009.hostedemail.com [216.40.44.9]) by kanga.kvack.org (Postfix) with ESMTP id 973256B00C2 for ; Thu, 3 Jun 2021 10:51:28 -0400 (EDT) Received: from smtpin07.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay01.hostedemail.com (Postfix) with ESMTP id 20A25180AD801 for ; Thu, 3 Jun 2021 14:51:28 +0000 (UTC) X-FDA: 78212701056.07.B2C1519 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by imf08.hostedemail.com (Postfix) with ESMTP id CD87F8019582 for ; Thu, 3 Jun 2021 14:51:13 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1622731887; 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=/JjgwFwgty+wYAd/TLY0hKsG0HookeJ8kkNgd0KRSnY=; b=RrvT/USc38v98INCsGUq+sXmx110eMmmnqf+/vLVSP11IrV4ViJVHq1MUw3MMy2OTtSWi/ IxZMG6aMNRN4Ju4fvSvj6c/5bnLEAX07DngUiFGTK+D2Bh++GvB57an9iibMu0P1wqmf8l GK10qHfGe8l9zM6kprgHvwa1plmFtZ4= Received: from mail-qv1-f70.google.com (mail-qv1-f70.google.com [209.85.219.70]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-450-9cpQXTcTO0iXpUN86EWwxQ-1; Thu, 03 Jun 2021 10:51:22 -0400 X-MC-Unique: 9cpQXTcTO0iXpUN86EWwxQ-1 Received: by mail-qv1-f70.google.com with SMTP id n12-20020a0c8c0c0000b02901edb8963d4dso4550838qvb.18 for ; Thu, 03 Jun 2021 07:51:22 -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=/JjgwFwgty+wYAd/TLY0hKsG0HookeJ8kkNgd0KRSnY=; b=m6WZ1XAhkjDIZYhBudHkC7JpRa4dFBikm8p03cB0EOJbl4qkBA3vulv87gzIC6Qjb1 i09U6YxHFQIRJRFIIyvIVksYUGpGaw9BE1Sr2Z1Nox6ldtcGEyh8Jzaac7GQ+/uvCbQU IbngtIyWRhmVtRZlQpO4aGL0fbHejNFZyDIWQYiUbRMBKxfPHbHAFrDMKzYRZfv2giik SRmP4pkkv2o5eSHoJGexBZbJi8Fzbs+rcgq+/FKzbPU0rqVcDldoUge+a7UO1yYnnAJq FwTteMqYl3kUpOB28Izj55iHBqqvB40PbLfsyPputVuUx9WjwfBva3bB3vrDOkrhGTjn frFQ== X-Gm-Message-State: AOAM5326Y7di1BaQJ9Th9axS3kwap0X/g27PcIZfk/jyTLAT8buG5We6 BlXkSaj/M+Wv7g0pYYNaxfmUVl4+LiHeVBKU9/dTApuWhGTz7eu9m3kZbNHHaRxCM/qy1SnZGQt pXnb9SGwHg6w= X-Received: by 2002:ac8:5315:: with SMTP id t21mr278792qtn.180.1622731882367; Thu, 03 Jun 2021 07:51:22 -0700 (PDT) X-Google-Smtp-Source: ABdhPJyZjzyXrgNjkDGMNnlrVXA18VUx+lYgw3Yq3/AzYYZJgnMoemc9xdQbWqvswJ10U6mETTLfhg== X-Received: by 2002:ac8:5315:: with SMTP id t21mr278757qtn.180.1622731882132; Thu, 03 Jun 2021 07:51:22 -0700 (PDT) Received: from t490s (bras-base-toroon474qw-grc-61-184-147-118-108.dsl.bell.ca. [184.147.118.108]) by smtp.gmail.com with ESMTPSA id n194sm2078914qka.66.2021.06.03.07.51.20 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 03 Jun 2021 07:51:21 -0700 (PDT) Date: Thu, 3 Jun 2021 10:51:19 -0400 From: Peter Xu To: Alistair Popple Cc: linux-kernel@vger.kernel.org, linux-mm@kvack.org, Axel Rasmussen , "Kirill A . Shutemov" , Hugh Dickins , Andrew Morton , Miaohe Lin , Mike Rapoport , Jerome Glisse , Andrea Arcangeli , Nadav Amit , Mike Kravetz , Jason Gunthorpe , Matthew Wilcox Subject: Re: [PATCH v3 04/27] mm/userfaultfd: Introduce special pte for unmapped file-backed mem Message-ID: References: <20210527201927.29586-1-peterx@redhat.com> <4422901.rTkcW5k3cD@nvdebian> <4688876.HeLTNyGTSD@nvdebian> MIME-Version: 1.0 In-Reply-To: <4688876.HeLTNyGTSD@nvdebian> X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Authentication-Results: imf08.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b="RrvT/USc"; dmarc=pass (policy=none) header.from=redhat.com; spf=none (imf08.hostedemail.com: domain of peterx@redhat.com has no SPF policy when checking 170.10.133.124) smtp.mailfrom=peterx@redhat.com X-Rspamd-Server: rspam05 X-Rspamd-Queue-Id: CD87F8019582 X-Stat-Signature: befdzdi3x8ua695atro4egc4gqphak73 X-HE-Tag: 1622731873-67694 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, Jun 03, 2021 at 09:53:45PM +1000, Alistair Popple wrote: > On Friday, 28 May 2021 10:56:02 PM AEST Peter Xu wrote: > > On Fri, May 28, 2021 at 06:32:52PM +1000, Alistair Popple wrote: > > > On Friday, 28 May 2021 6:19:04 AM AEST Peter Xu wrote: > > > > This patch introduces a very special swap-like pte for file-backed > > > > memories. > > > > > > > > Currently it's only defined for x86_64 only, but as long as any arch > > > > that > > > > can properly define the UFFD_WP_SWP_PTE_SPECIAL value as requested, it > > > > should conceptually work too. > > > > > > > > We will use this special pte to arm the ptes that got either unmapped or > > > > swapped out for a file-backed region that was previously wr-protected. > > > > This special pte could trigger a page fault just like swap entries, and > > > > as long as the page fault will satisfy pte_none()==false && > > > > pte_present()==false. > > > > > > > > Then we can revive the special pte into a normal pte backed by the page > > > > cache. > > > > > > > > This idea is greatly inspired by Hugh and Andrea in the discussion, > > > > which is referenced in the links below. > > > > > > > > The other idea (from Hugh) is that we use swp_type==1 and swp_offset=0 > > > > as > > > > the special pte. The current solution (as pointed out by Andrea) is > > > > slightly preferred in that we don't even need swp_entry_t knowledge at > > > > all > > > > in trapping these accesses. Meanwhile, we also reuse _PAGE_SWP_UFFD_WP > > > > from the anonymous swp entries. > > > > > > So to confirm my understanding the reason you use this special swap pte > > > instead of a new swp_type is that you only need the fault and have no > > > extra > > > information that needs storing in the pte? > > > > Yes. > > > > > Personally I think it might be better to define a new swp_type for this > > > rather than introducing a new arch-specific concept. > > > > The concept should not be arch-specific, it's the pte that's arch-specific. > > Right, agree this is a minor detail. I can't say it's a minor detail, as that's still indeed one of the major ideas that I'd like to get comment for within the whole series. It's currently an outcome from previous discussion with Andrea and Hugh, but of course if there's better idea with reasoning I can always consider to rework the series. > > > > swp_type entries are portable so wouldn't need extra arch-specific bits > > > defined. And as I understand things not all architectures (eg. ARM) have > > > spare bits in their swap entry encoding anyway so would have to reserve a > > > bit specifically for this which would be less efficient than using a > > > swp_type. > > It looks a trade-off to me: I think it's fine to use swap type in my series, > > as you said it's portable, but it will also waste the swap address space > > for the arch when the arch enables it. > > > > The format of the special pte to trigger the fault in this series should be > > only a small portion of the code change. The main logic should still be the > > same - we just replace this pte with that one. IMHO it also means the > > format can be changed in the future, it's just that I don't know whether > > it's wise to take over a new swap type from start. > > > > > Anyway it seems I missed the initial discussion so don't have a strong > > > opinion here, mainly just wanted to check my understanding of what's > > > required and how these special entries work. > > > > Thanks for mentioning this and join the discussion. I don't know ARM enough > > so good to know we may have issue on finding the bits. Actually before > > finding this bit for file-backed uffd-wp specifically, we need to firstly > > find a bit in the normal pte for ARM too anyways (see _PAGE_UFFD_WP). If > > there's no strong reason to switch to a new swap type, I'd tend to leave > > all these to the future when we enable them on ARM. > > Yeah, makes sense to me. As you say it should be easy to change and other > architectures need to find another bit anyway. Not sure how useful it will be > but I'll try and take a look over the rest of the series as well. I'll highly appreciate that. Thanks Alistair! -- Peter Xu