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 160E5C04A6A for ; Thu, 10 Aug 2023 21:54:20 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 855636B0071; Thu, 10 Aug 2023 17:54:19 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 805B56B0072; Thu, 10 Aug 2023 17:54:19 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 6F41F6B0074; Thu, 10 Aug 2023 17:54:19 -0400 (EDT) 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 615D76B0071 for ; Thu, 10 Aug 2023 17:54:19 -0400 (EDT) Received: from smtpin16.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id 108BB1CA1C9 for ; Thu, 10 Aug 2023 21:54:19 +0000 (UTC) X-FDA: 81109549038.16.FAABD48 Received: from casper.infradead.org (casper.infradead.org [90.155.50.34]) by imf23.hostedemail.com (Postfix) with ESMTP id 0724014000F for ; Thu, 10 Aug 2023 21:54:16 +0000 (UTC) Authentication-Results: imf23.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b=bRUN9usC; dmarc=none; spf=none (imf23.hostedemail.com: domain of willy@infradead.org has no SPF policy when checking 90.155.50.34) smtp.mailfrom=willy@infradead.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1691704457; 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=RU0sXhO2RQNDDSYdL7EeIXZJPLuZxUwbT9QsXnScSII=; b=F8iQU0r8kTG/fuyKySgd5HjSkQUy7PF14fNUypITAQ2mLM1wfhzO7utNqH3Fr5vLgtdjhh mI4Ji9w9E6JptWtZRkyV9n+MO8Bdv7tPM2zg2QHXGpMn+ptRd6U9O0bL/UuU/AXm8HKuPK 3yqeKEZq9NUXQhkZwgAKZio15lEnnAE= ARC-Authentication-Results: i=1; imf23.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b=bRUN9usC; dmarc=none; spf=none (imf23.hostedemail.com: domain of willy@infradead.org has no SPF policy when checking 90.155.50.34) smtp.mailfrom=willy@infradead.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1691704457; a=rsa-sha256; cv=none; b=fgqgjwSZChRLIMu+dbu2q7F9Vosb3ClsLsU0jmPdPtLbE9F/g9jXnJV5QmvbtP1sAbe13W BjDb0Oiw1Bsx6op0JNZeEVLrnu3INjqvK0COBlMBCe0Umcwpxm4OSvEa55N5qQDWjMUFST E+qvo1Dv1VJMFrrc2Ro1rtmP9kMlYKk= 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=RU0sXhO2RQNDDSYdL7EeIXZJPLuZxUwbT9QsXnScSII=; b=bRUN9usCQLHI82STQKPErTe238 j/e39iuEoltOdwRI4bvxOhW5+5HNFoWGzXga6QrC2eiUbxsdmrioGMxJoQx9t9rfEaqbXJPUKsPnQ iXdE7dfMGCuAShDLVrcGHkLBRrf8JxdXOp75lGbF/AFeTP3rVFCWdsshp1dfPcipglz1UFzbEngWp UKifiajJlzW7zG2FwDQQ6alxoV9JW1+l80uJLaN1RsJhmqhuP2ox5eFBM+YibPBJbf2Vu+C1sCFFA +n7LJ/H5cKWikDfiMz1JK8hvHk7hNdd7MRqvNq5U5rlnEFHZhCjZ7yfyRkO3pnYhKaUtSJx9J3Ve2 ANF3F+gg==; Received: from willy by casper.infradead.org with local (Exim 4.94.2 #2 (Red Hat Linux)) id 1qUDbZ-00EvTN-Re; Thu, 10 Aug 2023 21:54:06 +0000 Date: Thu, 10 Aug 2023 22:54:05 +0100 From: Matthew Wilcox To: Peter Xu Cc: David Hildenbrand , linux-kernel@vger.kernel.org, linux-mm@kvack.org, linux-doc@vger.kernel.org, Andrew Morton , Jonathan Corbet , Mike Kravetz , Hugh Dickins , Ryan Roberts , Yin Fengwei , Yang Shi , Zi Yan Subject: Re: [PATCH mm-unstable v1] mm: add a total mapcount for large folios Message-ID: References: <20230809083256.699513-1-david@redhat.com> <7e31254d-8889-7e79-50e1-2630bd493d59@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspamd-Queue-Id: 0724014000F X-Rspam-User: X-Rspamd-Server: rspam04 X-Stat-Signature: wmwna7k5km5xjf6w5adqk11k1mrry4ra X-HE-Tag: 1691704456-870881 X-HE-Meta: U2FsdGVkX19ptDAYDAcKFHrvoiqv30mfCmlImwQwqQ2XBOeLS8wn+vlPPgjGPVeTCzMujJA6MT/z53uD8eYJe/VZ6MDt+9yd3JWXdTBH+RPMfSveLHsg/Jj9R/gojF8L+xZMvjplly9kYq18rjoJTK8Q44GaYqjNtvz9yvIwHCwi6KgHHYu6NkT1grTXlnnSnUf7miV6LE4QyYJoTZLa9csj7xDSl+DT1mFBc5FiQtPeLisQ6h1NbXxuutskbEeC33kgEQNZ9ZNIMsFoBr7B7jIuc2YQDwtxK9EkyYJhmgml2Oc/iQMXR9C18qtkxIr+2UU9K/1KyMjI7h1J5LZfKhCieSMY0YO0AfURXgisZmll+8QMtMG/sOwBR0iFTqBk2WYLtgN/VQHyIz7JSOpEBYmT9az0vZPKP9zBoFx1//E//SGyBZUc+hzkszpj0Tl+BKx2yLlrHj2Dj+GT7LMaYT8dhCUKGBAjMSPR3aZA598HGMvgti23mYSlvQAkO6GiFeE8i3HvsWHu5ew+70NL7++247BCA/XLpzS9OHRr2LCpUqB6GEi0fgK8izsFylICtvdd9grpDN1m7VrKAdsqdgEqY7yBh7dG1Le3/q993kvp7IDb5NTOj6wurrUvi2NKeVmPdDymHlvyAogeTM7yH5KJEavNloyPc9h5wIs+imceLyRz8WJ22e7WkLMCl+5VYNG4QKYcZSBlB8jmW0/jQx+E/Cyz6Lhh/uG5FHxsokMf6fxBYM9CVX/HtiEKwixbISaAQGI6hxprzHWioHB/iHnRILWNUNAgsupc1mofPmSlgTxg6NHXqIPKpjE9vMJk6n3pp/BqQzYPBD8XOvKRoNezRXnO+CWwI0z4KIhksy4Y/Loo+NolG5D3TUKqEsuofuidNBp9nf2MfCnW37Y+FZuYnfXMCZAMB/r/r0AVwr2yLiTcPBQnIgF6u/cpfc0Lwxvqwe3HTorA6komE36 CeIch8/Z h0UZWEgRw/Ld6VIbpCgjsavZzDXY11m5ECs/1Xy97rbTyvmfvrkqGgi6uKBFs001M45UD+aAEDTw5idjmTW7Lsa7OoyMqfG7zoJZ6VHrxj0FG4gOBU+tAD66sKDZKi55KFnpb3ICTfsFHaHY= 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 Thu, Aug 10, 2023 at 05:48:19PM -0400, Peter Xu wrote: > > Yes, that comment from Hugh primarily discusses how we could possibly > > optimize the loop, and if relying on folio_nr_pages_mapped() to reduce the > > iterations would be racy. As far as I can see, there are cases where "it > > would be certainly a bad idea" :) > > Is the race described about mapcount being changed right after it's read? > Are you aware of anything specific that will be broken, and will be fixed > with this patch? The problem is that people check the mapcount while holding no locks; not the PTL, not the page lock. So it's an unfixable race. > Having a total mapcount does sound helpful if partial folio is common > indeed. > > I'm curious whether that'll be so common after the large anon folio work - > isn't it be sad if partial folio will be a norm? It sounds to me that's > the case when small page sizes should be used.. and it's prone to waste? The problem is that entire_mapcount isn't really entire_mapcount. It's pmd_mapcount. I have had thoughts about using it as entire_mapcount, but it gets gnarly when people do partial unmaps. So the _usual_ case ends up touching every struct page. Which sucks. Also it's one of the things which stands in the way of shrinking struct page. But it's kind of annoying to explain all of this to you individually. There have been hundreds of emails about it over the last months on this mailing list. It would be nice if you could catch up instead of jumping in.