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 1CA47C47422 for ; Mon, 29 Jan 2024 13:49:37 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id A08146B009F; Mon, 29 Jan 2024 08:49:36 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 9B8576B00A4; Mon, 29 Jan 2024 08:49:36 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 880B76B00AD; Mon, 29 Jan 2024 08:49:36 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0015.hostedemail.com [216.40.44.15]) by kanga.kvack.org (Postfix) with ESMTP id 72C8E6B009F for ; Mon, 29 Jan 2024 08:49:36 -0500 (EST) Received: from smtpin26.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay05.hostedemail.com (Postfix) with ESMTP id 1966D40A36 for ; Mon, 29 Jan 2024 13:49:36 +0000 (UTC) X-FDA: 81732481152.26.3F061C1 Received: from casper.infradead.org (casper.infradead.org [90.155.50.34]) by imf29.hostedemail.com (Postfix) with ESMTP id 2CCCD12002A for ; Mon, 29 Jan 2024 13:49:33 +0000 (UTC) Authentication-Results: imf29.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b=q6xWleBs; spf=none (imf29.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=1706536174; 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=P04wO7NUHklEN0Q7y8PLetDTQZGz0bRmcbZ3a3Avlf0=; b=DuubE36F6MgBZhMyBVhrx2BAT1g9sQjtxQAD+wsHNT54uovcVBXd/A8mcDQ9FxoPdUMG6Z Ns/zoI/IetHDblJ0nIOcvHpTLP/oOLXrxqb0Z9OITKBh15GWDfrZ7sEy5GwDKu/9tRYiph +xpU8bpHZgmP60fdZQRiePyYmTfHRQo= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1706536174; a=rsa-sha256; cv=none; b=52KQR7J3xXXooJqCoD87NaXYHNzp5jRyKVx1GxE4QAYaAKRvoteNdi1e9R6NMFCRuJBuLf QPEKojYOL5a/1gOrkvmmrk3lue6GNhWOwK9vbhMs/DWiHjjRQ1zvKzHqVJzSVErvscwHcF mbd6A6RT1d9FNZjiKo+JtkAXMMmFetc= ARC-Authentication-Results: i=1; imf29.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b=q6xWleBs; spf=none (imf29.hostedemail.com: domain of willy@infradead.org has no SPF policy when checking 90.155.50.34) smtp.mailfrom=willy@infradead.org; dmarc=none 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=P04wO7NUHklEN0Q7y8PLetDTQZGz0bRmcbZ3a3Avlf0=; b=q6xWleBsEV1xwqcBp47i30s0yW rr3HvFIBavyEJ5Zlucb84j7E6qU3PmlTCVkvnKtWGRlau/kN5mmtEso/qwVrwWDdlyuIhR/q8yfVH o/v89RdteEY5pZrZngJknycIIPO/9yUiYWXEE6PFTiruoCaeP56RAZaWq9CneYJn2q1JMnd1K4hbc ji71uVsEBgIMQ3VuAuRFJdM8VPF5RQUsgtkgd2vDvYO9YZvu7EF3lfDqp+rxkJAACYkmd5pzTdIRl T1zp+oyRFdJrv2xlW4oUB5d6BLMgnB+N4L8N7dkKSrzJtDS3XlmUjfoY3NwJbrQNULHRG5ANpHwWB r/HmJFzw==; Received: from willy by casper.infradead.org with local (Exim 4.97.1 #2 (Red Hat Linux)) id 1rUS0w-00000006lMC-2x8Z; Mon, 29 Jan 2024 13:49:30 +0000 Date: Mon, 29 Jan 2024 13:49:30 +0000 From: Matthew Wilcox To: David Hildenbrand Cc: lsf-pc@lists.linux-foundation.org, "linux-mm@kvack.org" , Michal Hocko , Dan Williams Subject: Re: [LSF/MM/BPF TOPIC] MM: Mapcount Madness Message-ID: References: <049e4674-44b6-4675-b53b-62e11481a7ce@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <049e4674-44b6-4675-b53b-62e11481a7ce@redhat.com> X-Rspamd-Queue-Id: 2CCCD12002A X-Rspam-User: X-Rspamd-Server: rspam11 X-Stat-Signature: w4iuusatpb4s7n3cjb4dnfxwqnrrjxc6 X-HE-Tag: 1706536173-230060 X-HE-Meta: U2FsdGVkX1+5h/UaW6ryi/i8dqKma0wqYGXc4ascMwkV4QMDeh8eGWwVfoX8vuFmPmmp85oHSyFwrgr8P/Brdc3TxBHnh3NEuoTtaftWB2zZJKIFyMTWmyQbHUOipGP/ypp/HQ+z9hShh8yoI3/5TJSIlESjdDBh3DtKeRV1R9hOri9ahH2e1AISo9f7usiIbqfk8Mig/+bk6cDKOx/TDZnLkcPV/xbZA9ZqJLto7vHJagoOHzQBvboH2+lg8Vyfo63Do/OcUbeD8FeM1AR8fRKowLGCRW5lzVlJxjwo4SfTk6tr2EmowTGfg3vbgjzxVcWovQVECo4hUf5MSLOcGAE1DX5sYqUKhiSOxqa1WAH0AsDtC6derZBRHyvt1qn6ZwIIZPEIXHHT2Nc5tnXIvB1bXFSxluSkqAAisrNmj6yUC2eVRFFNLBIwFhiu06udDOni+QcqDnvgVh/JjBzw1/RAnwHqZBpvXk5GFtTbH3Py+dc245axt6NmFaOJ/bxCf0/XyOrho27kcDoMGOfNrnbSExn6LASbnTUekeA203Rr0omWVGeWmSWBEZY/L8uFPyzWS3OecI7EiEf+TJuh1IdMuC/Ar1E/CF1Yq3FSRsL7eIisqzJpIxT9f+X+xCPADl8Oizu9ULlcLcL+Ty90G3P9Si0On+ZfhgdWFM4AiQxj++/NlRxSHFyckFtPWYBmfcO7tI5WIKg38Z8+zWsmf4dPQTik+pQYURV9EOS11ofAz8H0R5UVVxMYpKUn9f0rFAWuYUl2zXUZjCHEWOeU4eWZVtj9nCMHSmd1KAQyWAlWtRH+y2RUOMlELYUT6Wl81bKPy2hTsa2vrqkMExL8+4bCaR7p1d6Yr56FH6rENijbh9d5DwzNBbJL1wZEDxSs3M3nrp9VjbW5MwwwxgouUXgwQHMQznEqYUDehyCLZchZOF6E1t9FaRJ48j1vl9OC7lH3vvt00RNrGAkUMSe RXvnvPcL hC/fSNGoocYMr+o+wIg6OFNNGEJ1qVhA3EzhM7CKx1h891s659teen4kyP96dN+lmMn8Q2bJhR8HoBTHZl+imgfBgJkIZ9EvM+LBHLawEegsVsfffsP4NI3/xmb1H848ZU23S0Jm6BKYWVaCAwl/OOrLGdxkbwS28VftmL9O+SYaGBmt8H9sD0GD9qg== 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: List-Subscribe: List-Unsubscribe: On Mon, Jan 29, 2024 at 01:05:04PM +0100, David Hildenbrand wrote: > As PTE-mapped large folios become more relevant (mTHP [1]) and there is the > desire to shrink the metadata allocated for such large folios as well > (memdesc [2]), how we track folio mappings gets more relevant. Over the > years, we used folio mapping information to answer various questions: is > this folio mapped by somebody else? do we have to COW on write fault? how do > we adjust memory statistics? ... > > Let's talk about ongoing work in the mapcount area, get a common > understanding of what the users of the different mapcounts are and what the > implications of removing some would be: which questions could we answer > differently, which questions would we not be able to answer precisely > anymore, and what would be the implications of such changes? > > For example, can we tolerate some imprecise memory statistics? How > expressive is the PSS when large folios are only partially mapped? Would we > need a transition period and glue changes to a new CONFIG_ option? Do we > really have to support THP and friends on 32bit? Excellent topics to cover. I have some of my own questions ... Are we in danger of overflowing page refcount too easily? Pincount isn't an issue here; we're talking about large folios, so pincount gets its own field. But with tracking one mapcount per PTE mapping of a folio, we can easily increment a PMD-sized folio's refcount by 512 per VMA. Now we only need 2^22 VMAs to hit the 2^31 limit before the page->refcount protections go into effect and operations start failing. How / do we need to track mapcount for pages mapped to userspace which are neither file-backed, nor anonymous mappings? eg drivers pass vmalloc memory to vmf_insert_page() in their ->mmap handler. What do VM_PFNMAP and VM_MIXEDMAP really imply? The documentation here is a little sparse. And that's sad, because I think we expect device driver writers to use them, and without clear documentation of what they actually do, they're going to be misused.