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 Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 13457C433EF for ; Sun, 19 Dec 2021 21:13:06 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 663F36B0078; Sun, 19 Dec 2021 16:12:50 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 6135D6B007B; Sun, 19 Dec 2021 16:12:50 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 4DC086B007D; Sun, 19 Dec 2021 16:12:50 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0244.hostedemail.com [216.40.44.244]) by kanga.kvack.org (Postfix) with ESMTP id 3FC2D6B0078 for ; Sun, 19 Dec 2021 16:12:50 -0500 (EST) Received: from smtpin27.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay01.hostedemail.com (Postfix) with ESMTP id 089C9180E4ECF for ; Sun, 19 Dec 2021 21:12:34 +0000 (UTC) X-FDA: 78935792628.27.5CCCE1D Received: from casper.infradead.org (casper.infradead.org [90.155.50.34]) by imf19.hostedemail.com (Postfix) with ESMTP id 703ED1A0030 for ; Sun, 19 Dec 2021 21:12:33 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=casper.20170209; h=In-Reply-To:Content-Type:MIME-Version: References:Message-ID:Subject:Cc:To:From:Date:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description; bh=zqlFDBLHajnmW6mUIPthSeuQfJKdlQjNzAtsDu8MOeQ=; b=tzKRd0PdZDTg6wWSKsTKnQJ+sN NuDm+zLpq0sHd09YzKzCFKNAn0pZHXnADRt4x7oNk+0wGxCZT4OSKCsXjzKtc1PCc3rPkJ7MJpKF1 65uWo3bUMXalRpgVUFGlSfITew3R6EBqH/kmYi4NSea+GVqPdref3E4884uQoTCrH2tpFtA/ihWNB wvcVCg8yV38ut+cSqikjvSNUpJ1mRbjm7OKwodEMdAXoVtKwVLt1YtRMjwksMcNgh5EVDvDLNyRKX cEnAKQAuHAqKkr1v6C9u+7zlLWafdjgNzMk54g7I/OxMDCN9g+ZEzqoNl35SgZu3LexTURLeoaZu7 8JJGApJg==; Received: from willy by casper.infradead.org with local (Exim 4.94.2 #2 (Red Hat Linux)) id 1mz3TN-0012HD-BR; Sun, 19 Dec 2021 21:12:01 +0000 Date: Sun, 19 Dec 2021 21:12:01 +0000 From: Matthew Wilcox To: David Hildenbrand Cc: Linus Torvalds , Nadav Amit , Jason Gunthorpe , Linux Kernel Mailing List , Andrew Morton , Hugh Dickins , David Rientjes , Shakeel Butt , John Hubbard , Mike Kravetz , Mike Rapoport , Yang Shi , "Kirill A . Shutemov" , Vlastimil Babka , Jann Horn , Michal Hocko , Rik van Riel , Roman Gushchin , Andrea Arcangeli , Peter Xu , Donald Dutile , Christoph Hellwig , Oleg Nesterov , Jan Kara , Linux-MM , "open list:KERNEL SELFTEST FRAMEWORK" , "open list:DOCUMENTATION" Subject: Re: [PATCH v1 06/11] mm: support GUP-triggered unsharing via FAULT_FLAG_UNSHARE (!hugetlb) Message-ID: References: <20211218184233.GB1432915@nvidia.com> <5CA1D89F-9DDB-4F91-8929-FE29BB79A653@vmware.com> <4D97206A-3B32-4818-9980-8F24BC57E289@vmware.com> <5A7D771C-FF95-465E-95F6-CD249FE28381@vmware.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Authentication-Results: imf19.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b=tzKRd0Pd; spf=none (imf19.hostedemail.com: domain of willy@infradead.org has no SPF policy when checking 90.155.50.34) smtp.mailfrom=willy@infradead.org; dmarc=none X-Rspamd-Server: rspam06 X-Rspamd-Queue-Id: 703ED1A0030 X-Stat-Signature: tie4iidgq3dq9d6gymn1zztwgonrwa9o X-HE-Tag: 1639948353-964851 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 Sun, Dec 19, 2021 at 06:59:51PM +0100, David Hildenbrand wrote: > On 19.12.21 18:44, Linus Torvalds wrote: > > David, you said that you were working on some alternative model. Is it > > perhaps along these same lines below? > > > > I was thinking that a bit in the page tables to say "this page is > > exclusive to this VM" would be a really simple thing to deal with for > > fork() and swapout and friends. > > > > But we don't have such a bit in general, since many architectures have > > very limited sets of SW bits, and even when they exist we've spent > > them on things like UDDF_WP., > > > > But the more I think about the "bit doesn't even have to be in the > > page tables", the more I think maybe that's the solution. > > > > A bit in the 'struct page' itself. > > > > Exactly what I am prototyping right now. > > > For hugepages, you'd have to distribute said bit when you split the hugepage. > > Yes, that's one tricky part ... That part shouldn't be that tricky ... Can we get rid of ->mapcount altogether? Three states: - Not mapped - Mapped exactly once - Possibly mapped more than once I appreciate "Not mapped" is not a state that anon pages can meaningfully have (maybe when they go into the swap cache?) And this information would only be present on the head page (ie stored per folio). If one VMA has multiple PTEs that map the same folio, then hopefully that only counts as mapped once. I must admit about half this conversation is going over my head. I need more time to understand all the constraints than exists between emails :-)