Received: by 2002:a05:6a10:1287:0:0:0:0 with SMTP id d7csp3900454pxv; Mon, 19 Jul 2021 11:29:47 -0700 (PDT) X-Google-Smtp-Source: ABdhPJy821mUEqkskTU9x+803AGS2gZkD3laWrtvf8bJzYh8FEUeKqMGVlk8kKcl+JgiIGMsP3O2 X-Received: by 2002:a92:dd89:: with SMTP id g9mr18299600iln.209.1626719387582; Mon, 19 Jul 2021 11:29:47 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1626719387; cv=none; d=google.com; s=arc-20160816; b=caAtvY1lb7l51qA9qn2fNV6zDNHRGw73ihZuU3phC497ZGfXdg8YZcppBN1XyStsb7 EGSsUfBiIeIyFb/x/323PjHx4ZSNGaCpWfhtOa4RWuptzuxpzhCY/4Kr0M/mCnw3V10X Gc8jx2bi3FPvWLrjGnJq2xUxxgovUmV9QfVf1GRENzzRfcodoHcyJFCYatxY2MOtnsYx SyXci2vkn3jCgB3QTDUnSA6hRvDkeSC1xXQR3fyUx0P7b1kviO8Q6wlra7mBQvBFjipE wZJQsQXisv+dOfbea9iZhj47df6m3Ox0E3GoaQRnipcrECLh26uwZzANYdOoAsSSznNB vWQA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-disposition:mime-version :references:message-id:subject:cc:to:from:date:dkim-signature; bh=eBElLwqpPID1BN8TMn/1i6CmvM212NI5w9OKbU1jkvk=; b=j8zecxMnzbDBygdsvoNy3YfbrC5HA0pfPmLXXNpj5InP8Mb5kbsarxry5SvNcqnUdN of/Gn0amZjIdoLn29jkxQw7jtf2wemaG2Cn6NYE4pCHaxGxxjSdHBNz096lDOiJZVsHi yJ/XOiR8f7id0jGA2qnupni6E5d20IFdCAYe7XGBJbdvBuGFQBemw/obIFJnY9GERBB5 hvw5DHTdUX5IIBVYH9Sl0DOZStox/2lNlQTKcK2b0UyYeZBiTBJeiQWH35yqENAUv1OA h/8el6pwXNkGHdAzRvOPw1vTbPVsnyEkX9SonBGWtvgMWtBMRIMkq4OujZ5YUFVjothE ccNQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=dWcrfaoG; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id o22si18760955jat.98.2021.07.19.11.29.35; Mon, 19 Jul 2021 11:29:47 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=dWcrfaoG; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1382914AbhGSRnU (ORCPT + 99 others); Mon, 19 Jul 2021 13:43:20 -0400 Received: from us-smtp-delivery-124.mimecast.com ([216.205.24.124]:30155 "EHLO us-smtp-delivery-124.mimecast.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1359311AbhGSRPu (ORCPT ); Mon, 19 Jul 2021 13:15:50 -0400 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-qk1-f198.google.com (mail-qk1-f198.google.com [209.85.222.198]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-161-dnkdytnbNCiP2HFDaXuSnA-1; Mon, 19 Jul 2021 13:56:24 -0400 X-MC-Unique: dnkdytnbNCiP2HFDaXuSnA-1 Received: by mail-qk1-f198.google.com with SMTP id b127-20020a3799850000b02903b960837cbfso3230943qke.10 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=axAIa27J+cywrX32p8yH4o77KfG4NtE2+oFVS2SpgNVE4WPc4JUNdPyosvF6UnXZkn 8KW10p9BdP2mKu5FwG2efEKDnqshP8/SzY591Tq692huXbVNxeQJ8/CWs0kfzdxCXxEZ Qme9IzMKxyn8pZi8vdWIzXFQeD1OjqxkeH+ciN4ORJL/VXf/2SEZ7XFoBfO/tR8pRyFt IIU6BQKeYrkCdF1FCpH6kUXlgEMrfi5O0DGRp+Vt2i9c6FYEPoydOJUkUkFLM48LaXE3 RLBZ8gMrrkwUQlsQZCYgsEPCrAyEwRUhqLn5R3+C0fjdE8pmBGwKUMlT3LD9xsmMhhvM o4jg== X-Gm-Message-State: AOAM532qUXOdJNO8ZtKrw6co1SeO+3xgzuTK6pN+CnXZ+qBASV0vWFKw Cq2ug0MFW9i9J5NI478Sv2eNQsrhjoy6X1yhgYLvYn5vQ1lgOw8Ikzij+M9f9nxG0/EZH5ASGCL OzE58AxJfHoqehQExsYcKOLNO X-Received: by 2002:a05:6214:5b0:: with SMTP id by16mr25324031qvb.54.1626717384025; Mon, 19 Jul 2021 10:56:24 -0700 (PDT) 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 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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