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=-7.2 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 4346EC07E95 for ; Mon, 19 Jul 2021 17:56:28 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id D90A861006 for ; Mon, 19 Jul 2021 17:56:27 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org D90A861006 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 3B6918D00F4; Mon, 19 Jul 2021 13:56:28 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 366908D00EC; Mon, 19 Jul 2021 13:56:28 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 1E0528D00F4; Mon, 19 Jul 2021 13:56:28 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0125.hostedemail.com [216.40.44.125]) by kanga.kvack.org (Postfix) with ESMTP id E8DF48D00EC for ; Mon, 19 Jul 2021 13:56:27 -0400 (EDT) Received: from smtpin27.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay01.hostedemail.com (Postfix) with ESMTP id 7D845184B1FF1 for ; Mon, 19 Jul 2021 17:56:26 +0000 (UTC) X-FDA: 78380091972.27.0838770 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by imf26.hostedemail.com (Postfix) with ESMTP id 17C46201656E for ; Mon, 19 Jul 2021 17:56:25 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1626717385; 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=eBElLwqpPID1BN8TMn/1i6CmvM212NI5w9OKbU1jkvk=; b=dWcrfaoG9UQ2aLV+CNoMsF1yzKUmcz2HnmlyMttv1QarGlD5GU5jhqQm+6t7x0CiFqFuwg C28Z6NzJpy4/SQN1ovqhmZolBBIwLHxBnllL+ui42ieCeH8SYg5ps8PVvs6bFPcIZDDNt4 IfruRE9GJgrzJNpnoH+Z52MX1H9psqM= Received: from mail-qt1-f199.google.com (mail-qt1-f199.google.com [209.85.160.199]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-578-b7eyDpiXNTaGOPCyBL5i4g-1; Mon, 19 Jul 2021 13:56:24 -0400 X-MC-Unique: b7eyDpiXNTaGOPCyBL5i4g-1 Received: by mail-qt1-f199.google.com with SMTP id d11-20020ac851cb0000b02902536d2bea0fso9975217qtn.19 for ; Mon, 19 Jul 2021 10:56:24 -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=eBElLwqpPID1BN8TMn/1i6CmvM212NI5w9OKbU1jkvk=; b=Zj6fLlw6YkIHAii73EvRJDa37f9JLiR2JKs2Ysdss5dy65DUT1wPGUZZ7LcNS5j+uV tTYfFPe/72BpJI5ubz+tKpqenYV4uHzxxXJF1WUWVbFaxmI8DozBttGIgh+rU84QR999 sBEQiBEWi5JxmKXd/0B6Dvck4R/XWfb/BsXw2rg6Xz/8uLcvaspTNxE1065DOqgEkNaw xizNPrX4PtjEUU9sqR8BuYImnXXNA/y0Ev3XzrC3LcNS+KBVeDFAwSdPx8PSdKV5Hhuq 9kc+sVYrtibMuGRcR3ZOdxCYJLJyr+DVBGzVKB70lO1jkpX2h/0UIXbWP3zHZtkL4dOM rbUQ== X-Gm-Message-State: AOAM530A+ZELC/TcqVGlsnDcqt1ElrKChSEMpaEYMiOgm0TpJD7tskLR MkucmrRybMq2DYZTE6CYA4f6YBpTpCM9TgAwrtNCLoFr7IuI5xiTtpiEJY2T2jKHEItD8pCWOve 9DYGQv88aHZk= X-Received: by 2002:a05:6214:5b0:: with SMTP id by16mr25324048qvb.54.1626717384034; Mon, 19 Jul 2021 10:56:24 -0700 (PDT) X-Google-Smtp-Source: ABdhPJxQqqNgBSoRaZRpSdWGiX4A4izIiy1gA3EJPG/ihB1Ef+eISSJmMPKR3BzAg9FgcvLKhLcnNg== X-Received: by 2002:a05:6214:5b0:: with SMTP id by16mr25324012qvb.54.1626717383819; Mon, 19 Jul 2021 10:56:23 -0700 (PDT) Received: from t490s (bras-base-toroon474qw-grc-65-184-144-111-238.dsl.bell.ca. [184.144.111.238]) by smtp.gmail.com with ESMTPSA id p64sm8356183qka.114.2021.07.19.10.56.21 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 19 Jul 2021 10:56:22 -0700 (PDT) Date: Mon, 19 Jul 2021 13:56:21 -0400 From: Peter Xu To: Tiberiu Georgescu Cc: "linux-kernel@vger.kernel.org" , "linux-mm@kvack.org" , Axel Rasmussen , Nadav Amit , Jerome Glisse , "Kirill A . Shutemov" , Jason Gunthorpe , Alistair Popple , Andrew Morton , David Hildenbrand , Andrea Arcangeli , Matthew Wilcox , Mike Kravetz , Hugh Dickins , Miaohe Lin , Mike Rapoport , Ivan Teterevkov , "Carl Waldspurger [C]" , Florian Schmidt Subject: Re: [PATCH v5 24/26] mm/pagemap: Recognize uffd-wp bit for shmem/hugetlbfs Message-ID: References: <20210715201422.211004-1-peterx@redhat.com> <20210715201651.212134-1-peterx@redhat.com> MIME-Version: 1.0 In-Reply-To: X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Authentication-Results: imf26.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=dWcrfaoG; spf=none (imf26.hostedemail.com: domain of peterx@redhat.com has no SPF policy when checking 170.10.133.124) smtp.mailfrom=peterx@redhat.com; dmarc=pass (policy=none) header.from=redhat.com X-Rspamd-Server: rspam05 X-Stat-Signature: s7eobmh7pbegxxk89ebuwii77jzxymws X-Rspamd-Queue-Id: 17C46201656E X-HE-Tag: 1626717385-849323 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, Jul 19, 2021 at 05:23:14PM +0000, Tiberiu Georgescu wrote: > > What we're clear is we know it's uffd wr-protected, so maybe setting PM_UFFD_WP > > is still the simplest? > > That's right, but if we were to require any of the differentiations above, how > does keeping another bit on the special pte sound to you? One to signal the location on swap or otherwise (none or zapped). I don't know how to do it even with an extra bit in the pte. The thing is we need some mechanism to trigger the tweak of that bit in the pte when switching from "present" to "swapped out", while I don't see how that could be done. Consider when page reclaim happens, we'll unmap and zap the ptes first before swapping the pages out, then when we do the pageout() we've already released the rmap so no way to figure out which pte to tweak, afaiu. It also looks complicated just for maintaining this information. > > Is there any other clearer way to do it? We wouldn't want to overload the > special pte unnecessarily. I feel like the solution you proposed in the other patch for soft dirty might work. It's just that it seems heavier, especially because we'll try to look up the page cache for every single pte_none() (and after this patch including the swap special pte) even if the page is never accessed. I expect it will regress the case of a normal soft-dirty user when the memory is sparsely used, because there'll be plenty of page cache look up operations that are destined to be useless. I'm also curious what would be the real use to have an accurate PM_SWAP accounting. To me current implementation may not provide accurate value but should be good enough for most cases. However not sure whether it's also true for your use case. Thanks, -- Peter Xu