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 EC717C61DA4 for ; Thu, 2 Feb 2023 15:32:02 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 8EF316B0073; Thu, 2 Feb 2023 10:32:02 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 877816B007E; Thu, 2 Feb 2023 10:32:02 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 718AA6B0082; Thu, 2 Feb 2023 10:32:02 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0013.hostedemail.com [216.40.44.13]) by kanga.kvack.org (Postfix) with ESMTP id 5F8546B0073 for ; Thu, 2 Feb 2023 10:32:02 -0500 (EST) Received: from smtpin27.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id 3934D140F78 for ; Thu, 2 Feb 2023 15:32:02 +0000 (UTC) X-FDA: 80422742484.27.758C577 Received: from casper.infradead.org (casper.infradead.org [90.155.50.34]) by imf11.hostedemail.com (Postfix) with ESMTP id 5AD694001A for ; Thu, 2 Feb 2023 15:32:00 +0000 (UTC) Authentication-Results: imf11.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b=F3Z1kWrB; spf=none (imf11.hostedemail.com: domain of willy@infradead.org has no SPF policy when checking 90.155.50.34) smtp.mailfrom=willy@infradead.org; dmarc=none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1675351920; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=GQ67KFYjKy83OpHI36xAjENhzjEmn0vPDmda/p7GTlE=; b=hN6nn4ughIIBgq0w71+UdQDVBO8AHsshUUP13R8sBhLgVWJ9wUaC8E73xe54PN5wQ1brY1 tifHBCXz1q7FPNAkAqhjOIczX1EwILWlDi74EozzGYhqEb/OXt+TTMkTKIbZ0CZdit75vl ohP5l91ORlRguy1t7KSjZGb2e0x5mQo= ARC-Authentication-Results: i=1; imf11.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b=F3Z1kWrB; spf=none (imf11.hostedemail.com: domain of willy@infradead.org has no SPF policy when checking 90.155.50.34) smtp.mailfrom=willy@infradead.org; dmarc=none ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1675351920; a=rsa-sha256; cv=none; b=Ril7igCrdgqICz/+aV3iuuH/Awti/fJBys20OpKqaFk/ViNPbShsh9av2EmsnkaMY4E2mc qWkSY7dHZrfYjUnYeOZjinOMDoGbC65fyk9C0cGFDNOC1U9e1X2ODKL6tMqEPV+jW2immB K23Z8UeCg+/3E2HFOcrHNEe8nZJzV0g= 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=GQ67KFYjKy83OpHI36xAjENhzjEmn0vPDmda/p7GTlE=; b=F3Z1kWrBggfdHGb1W/mxG9R0Ly JFIE5qV6wTlFbe17H1WXYH9g1XEFncWP147tslFwjso25dgVe+jqo1nj5x+swHLBYUY85XpJKjrsj xKn+7eSFoSfBO4GGCYHoXZcvuJ6X+E0i/GWLfiyEb0SIF68trdiahR6M2lxYI39B5Gr1dKs3aHlKa cmw3gHjiUFYsgWq0dpFNFTKXEJG9yD58yQpt0eEjdreEQVXJpKWAWUUh7s/H1Cu9E8t+XmwOQBkq2 r/3bxzBIenbKtTgFRmLXiEVF8wnwox96wu4/0Yx4xjqEyAoxu+eeGh3NkKJYSC1BW9j9JFV37Ej0L c5PIndKQ==; Received: from willy by casper.infradead.org with local (Exim 4.94.2 #2 (Red Hat Linux)) id 1pNbZ3-00DVCT-Ri; Thu, 02 Feb 2023 15:31:53 +0000 Date: Thu, 2 Feb 2023 15:31:53 +0000 From: Matthew Wilcox To: Mike Kravetz Cc: linux-mm@kvack.org, Vishal Moola , Hugh Dickins , Rik van Riel , David Hildenbrand , "Yin, Fengwei" Subject: Re: Folio mapcount Message-ID: References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspam-User: X-Rspamd-Server: rspam03 X-Stat-Signature: 8z5rm9p4h487nbmtpze77jrebis554e9 X-Rspamd-Queue-Id: 5AD694001A X-HE-Tag: 1675351920-741440 X-HE-Meta: U2FsdGVkX18c9NtoDfRamwmXEcB50AV7bnhSr5HQUlhLLvVhy4fPE3Ojk7orRKx/RdFlvPyJQVCmXkV7M45IQ1ALG/Wp6U/zvy851lPN85OroLJw165eTGeEHdlgdLUsu9Kjj3Ab169x1BMguuYv6Xn2P1G40h4RDPuKHKl9seRXLKed5aVRmq5DcObmNlslIM0Xbv/oAsHfG/l8BZAHb0rwbso27IcdMycdkN9OARGj4ea6JMQhOcZ14OtYfw7nUtHCEeG+znvMO/52kNXEGHf6ea8EySAJ/TpQo0WD/cbVuAIj08wRVcYHtbu3lcwR2R4QZBHbq7m0IiVlpXqf6i91Rv9w0ncfYgyJNy1/V0qKTO+r3HKD7isv3mgISykfs1Am08eN0zhwuRBNqW8lUp3oQR1VqIyWX3Jbt5upFtZpURlZI/61eST7ptTdm5WQ3ZOkDqQszK4Vzxe1VDzCKjjc41p/yMWDBb2YJyV3gpZ2076XIIZ42UhoMPdAffkMoS5xrIo+RZzxpkDBu1zcElrPkfKhlOKaIjYmx32hjuizIyJHqCI7mNLL+yUkjy/RJDqdg3bhct/7fb0eWHhWHWaUPwhwUDL6o/+ArAWJ2oSdRF3vBcWNhPpbtJnhFNoZD8IfQJi1CWiFdeVK0Bib+Fl2ltjg+vkWUGqPVmbdBu/IZxtxeS3hHa3cBs3mIsHyg5gl6MsHZWogIXx862AtnoWWEZMaZ4oMbTIkZYbTrK34Y+RAHyogFAbX6iKv+O3DcbT4tkP/+3MHG2sRTyTKtOM84+tYOiV7lh5yL/HqfJuEyUc7sR+RfJPnFIh5+pIGBGxySpxnpRk84U+j3ZoNkjJaJOO2BST/AZ48K+3HMsWJ0FWos7gXEiePrhjuV8Yd/i+nOvLxvscgVJEFiM7atgxMBPQO3Ci3f8EskHnvxmqk2m0VYgiKjvGfqO/YJdqcTL5tPEnYZUzLodz4yB/ YeI2LqnF 2qY/JJ7zjUM2fTMPjWujwizEsIDzTex9Cgi8z2sJzPwLAJqwOFZm1kzploj7TiqlsRJkD+xdFfgJfPOM9ksXCNEeNQC33j13coc0y5wZleYpOan9Dc70HE7c1ueKDgTaeCUVUAlzbN7FXfz6a5Sy0fKarwPdewF536ofki4PTSLezdmeWfQG8xYyy/SIjGFsx0wazkWkA079or+K57CY9nKyoUdS5sh5KIQFG 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 Wed, Feb 01, 2023 at 07:45:17PM -0800, Mike Kravetz wrote: > On 01/24/23 18:13, Matthew Wilcox wrote: > > Once we get to the part of the folio journey where we have > > one-pointer-per-page, we can't afford to maintain per-page state. > > Currently we maintain a per-page mapcount, and that will have to go. > > We can maintain extra state for a multi-page folio, but it has to be a > > constant amount of extra state no matter how many pages are in the folio. > > > > My proposal is that we maintain a single mapcount per folio, and its > > definition is the number of (vma, page table) tuples which have a > > reference to any pages in this folio. > > Hi Matthew, finally took a look at this. Can you clarify your definition of > 'page table' here? I think you are talking about all the entries within > one page table page? Is that correct? It certainly makes sense in this > context. > > I have always thought of page table as the entire tree structure starting at > *pgd in the mm_struct. So, I was a bit confused. But, I now see elsewhere > that 'page table' may refer to either. Yes, we're pretty sloppy about that. What I had in mind was: We have a large folio which is mapped at, say, (1.9MB - 2.1MB) in the user address space. There are thus multiple PTEs which map it and some of those PTEs belong to one PMD and the rest belong to a second PMD. It has a mapcount of 2 due to being mapped by PTE entries belonging to two PMD tables. If it were mapped at (2.1-2.3MB), it would have a mapcount of 1 due to all its PTEs belonging to a single PMD table. [ Mike & I spoke earlier this week about what should happen with mapcount and a theoretical aligned 1GB THP that has its PUD mapping split into PTE mappings. Splitting a PMD to PTEs does not affect the mapcount since all of the PTEs are now referenced from a single PMD table instead of from a PMD entry. But splitting a PUD to PTEs should increment the mapcount by 511 since the folio is now referenced from 512 PMD tables. ]