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 A9052C636CD for ; Tue, 7 Feb 2023 05:03:26 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id C6C856B007D; Tue, 7 Feb 2023 00:03:25 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id BF4F36B007E; Tue, 7 Feb 2023 00:03:25 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id ABDF96B0080; Tue, 7 Feb 2023 00:03:25 -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 995AE6B007D for ; Tue, 7 Feb 2023 00:03:25 -0500 (EST) Received: from smtpin14.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay04.hostedemail.com (Postfix) with ESMTP id 72D571A0B82 for ; Tue, 7 Feb 2023 05:03:25 +0000 (UTC) X-FDA: 80439302370.14.BB2AD05 Received: from casper.infradead.org (casper.infradead.org [90.155.50.34]) by imf18.hostedemail.com (Postfix) with ESMTP id 6DB161C0008 for ; Tue, 7 Feb 2023 05:03:22 +0000 (UTC) Authentication-Results: imf18.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b=HKmBNvTw; spf=none (imf18.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=1675746203; a=rsa-sha256; cv=none; b=Wez+QaWD2gyrS7zkPOLqkiDfa0f9n5x5+cB6C7JdoAY5+Y3biDk1wS5TsTfu+NrY37mZ/h dRJlDPP6mBfS8WG9GibMdnaejq61euK0W1Q27BbfOU4QtJvBOIcWie/ttB7dbNp/vwrpJ+ kqaMVF9n7KQN6vRigMswPKatIa6COLw= ARC-Authentication-Results: i=1; imf18.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b=HKmBNvTw; spf=none (imf18.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=1675746203; 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=b1LU9dCMPkgaDazBkOHxur3kHG699R9Ahl9RzbgHpTI=; b=FHlLjJtXZjHoPOReXz6eTFCrJ4ylvAi4nEGwaYbAamAEpjhaIPFUw4fjAfX1++CyJ4KAXy yHVCHeFhmmYwPj/iBjcB6yt7rV3XVsL0aX09134lFcsLIVZSQuGEewvznWDMNfBalLmIzg 1b1JuVM1J8VKHYU17+m0WuZ8HV1EJPE= 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=b1LU9dCMPkgaDazBkOHxur3kHG699R9Ahl9RzbgHpTI=; b=HKmBNvTwODUAMssRR3b6AFu/7j TbNkYJCTcEES43uBQWcrXjQBk13VObBHya9CcuA6/ZxC69h1sGb+dC4DJpXsY/ScI4yKg9AlKFG4u MU1kLASIU5D37TVV01bK16FdPJx1BZ2GXhtzibda3cQN+8XiceSk5IYIK6LtQISFx+aXJF4oiGgs7 sMjGMaqATi2gA7wko8ymdFGzxyBiFbGYthofarFLqihM/mHbNChNmgNNWuNSu7LL2yK3rf1FuwvPZ 6DsGKlm5Z26WxSz6syQbUefGe7Ho/cRJ2kmzFHDJ2mMP38JGvVcqikMEG+3kuJg2MneUDXfCMLqXZ LygOz3nA==; Received: from willy by casper.infradead.org with local (Exim 4.94.2 #2 (Red Hat Linux)) id 1pPG8S-00HTBd-P6; Tue, 07 Feb 2023 05:03:16 +0000 Date: Tue, 7 Feb 2023 05:03:16 +0000 From: Matthew Wilcox To: "Yin, Fengwei" Cc: linux-mm@kvack.org, dave.hansen@intel.com, tim.c.chen@intel.com, ying.huang@intel.com Subject: Re: [RFC PATCH 2/2] rmap: remove parameter 'compound' from foeio_add_file_rmap_range() Message-ID: References: <20230206153049.770556-1-fengwei.yin@intel.com> <20230206153049.770556-3-fengwei.yin@intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspam-User: X-Rspamd-Queue-Id: 6DB161C0008 X-Rspamd-Server: rspam01 X-Stat-Signature: dcjaojh7osqgrx8atsut9nna3z3ffcdf X-HE-Tag: 1675746202-43626 X-HE-Meta: U2FsdGVkX1+NwBG8oswECYiv6J9xHYTqBm1mOucS83gNy3aSFrsCnus55j9Zx7T6RAQDBRDrOgUqNkoYEUuW5VvDMMVM3mij7Vr9zHZyhsjI6X9l8vKxOC8gojCXdebL+2f9559NZD05cT4jB+cNoh4qdhFz48ZvWAGA5/V/LQXgDzZwW3Y0iJeUumncj+P8OWjE8uGRobvQXbzndS/H2q+23lrJA4inLmjdu8BHE6CLbpYZBnZos9jY2IllB4XCrVJy7zmblmhVfS18Tixr2pJ3yEJUpH1vrg10+Df0P/nAcWKUBuZbAdv7Ojrpz51XKZwU4vZOv8cZ+SY6D48IJlRHchap4fjOssEi9OMLozc+OBlQ783dvBYKfxd+YBW5ODqVv0LdyXBzghIWWRSp5ZfoSO/dKzlPpnx5I1gy2siTtmo+IuJ3tYzysF5EmGp19C89g99DhLjZb5oZoazKWk4+4l7QfrA9gu/CGQkspNCr2PpKJeRZLvqd2nOFCdkXJCIPtcvkRNmCZE7+fP99OyGPCKq6AcXPOrAqS+ZSC7HhmQa9S6JgFHH8kA9EAlRQiIsLh9vDZnqKWdxW/r6MpYNH+n+bHNZjRVmbAmJKjRHWecFjF7PfXBZVozfBE0gC3fIUbDxTtjK1qWNSY107CXHWi0OJgr/yr5PwQCBHHVIv967++k1SrGxCKOkI9jlZ4BOGAAWSmn71oriqVY8bXloun67GEbnBVkBBjSX+Y524RlGHn7UY17HMMUBrOW53UroLKdpDA83+FJtZA7daRUomTY4ANMe+ksXGyi1f29pTs/bWHeE/qsGAEVaWSkEfML4wX2rTlt65XgZcqhtMuj6WwWbDWonoNQDDnF30snsyB6BFk/r8zI8itSNOETDeEPkaLzOM0A0Y8h2PKb+O4luj/WZ8HRapCdFle3svQ3IznlEDhsHEZ22hOKdHCRH93jGzBOhILtuK2dP5HqY fFfieqKU 1w72n+R0jSY/HCAmITzAS8qLfIylNqIx7VFou+jF4If0QOYZsihMcbPjV32LXsAoa7nkIhLfCm0xVO8+rQFUOtlL4NUfnzHozJPAsB7bW6LZ8fZsQq9i59Kh0OGB71sMdN/mcQGVj3IBkI2rtuejkpH6hVKwpXMgwkPgVQMcc/1iUeyya3D8aA8oe7/nxoLXkP8tPXIOWR3Ijnrs= 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 Tue, Feb 07, 2023 at 10:44:10AM +0800, Yin, Fengwei wrote: > On 2/7/2023 12:50 AM, Matthew Wilcox wrote: > > On Mon, Feb 06, 2023 at 11:30:49PM +0800, Yin Fengwei wrote: > >> Remove parameter 'compound' from folio_add_file_rmap_range(). > >> > >> The parameter nr_pages is checked whether same as folio page > >> numbers to know whether it's entire folio operation. > > > > We can't do this yet. Even if a folio is large enough to be PMD mapped, > > it may have been mapped askew (or its PMD mapping may have been split). > > We still need the caller to tell us whether it's been mapped with > > a PMD or with PTEs. > OK. My understand is that the info about PMD mapped is only for > statistic update. Maybe move the PMD mapped statistic to caller. Alas, no. That 'compound' parameter really means "to be mapped by a PMD". And we need to change all of add_file, add_anon and remove at the same time, otherwise we don't know which counter to inc/dec in page_remove_rmap(). > Another thing I am not sure whether it's worthy: > What about maintaining total mapcount for folio? So we don't need to > query each page mapcount to know it. So we can use "total_mapoucnt > > mapped" to know whether the folio has at least one page mapped more > than once. > > The payback is that we need update total mapcount when map/unmap > the folio. Right, there are lots of mapcounts we _could_ maintain. The important thing to understand is who wants to know what. As I see it, there are three important things we need to know: 1. Is any page in this folio mapped? (everywhere that calls folio_mapped() or page_mapped()) 2. Is any page in this folio mapped more than once? (some madvise calls, migration) 3. How many refcounts does the mapcount account for? (splitting, compaction) Some of the things we use mapcount for today I consider to be unimportant. For example, shrink_folio_list() checks to see if there are any PMD mappings and will split it if there are not. This doesn't fit my vision of how the VM should work; I believe we should swap the entire folio out as a single unit. So I don't really want to think about maintaining total_mapcount, I want the concept of total_mapcount to go away and just have a single mapcount for each folio, instead of this complex mismash of entire_mapcount, mapcount and total_mapcount.