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 1BA4DC05027 for ; Mon, 6 Feb 2023 16:33:14 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 945AB6B0072; Mon, 6 Feb 2023 11:33:13 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 8CEB16B0073; Mon, 6 Feb 2023 11:33:13 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 76F336B0074; Mon, 6 Feb 2023 11:33:13 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0012.hostedemail.com [216.40.44.12]) by kanga.kvack.org (Postfix) with ESMTP id 632316B0072 for ; Mon, 6 Feb 2023 11:33:13 -0500 (EST) Received: from smtpin30.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay04.hostedemail.com (Postfix) with ESMTP id 20B8A1A0920 for ; Mon, 6 Feb 2023 16:33:13 +0000 (UTC) X-FDA: 80437411866.30.87E6C2D Received: from casper.infradead.org (casper.infradead.org [90.155.50.34]) by imf03.hostedemail.com (Postfix) with ESMTP id 53EF620025 for ; Mon, 6 Feb 2023 16:33:11 +0000 (UTC) Authentication-Results: imf03.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b=TmVMfRup; spf=none (imf03.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=1675701191; 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=Fz8H//fGCN/l/hW36Go9XyZtgnmMh++XjH8XbjFgENk=; b=8nbCswUnr9uR2M1iW69VbkQj8uwK4yQSvUY/6MxyPOCqOoYPdgKPWaBdHpbeQjmp3Ygcpb 4pmIhqJvPTxzemxRAQe4bfpz1ICsbwd5qCoHfjgi2tLNMZ6PhNi/mawh9dyXDI2uJzNo8O le+m3OjWQ/8wK5Rx5ee5R+chTUVxwYQ= ARC-Authentication-Results: i=1; imf03.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b=TmVMfRup; spf=none (imf03.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=1675701191; a=rsa-sha256; cv=none; b=OQf8OI9dIBu0WWHZMgcmvk5S8lLbsQEjas690nm+M167DW3E1h3ONe4DDJaI8NNRAEvPKs Kc+RVsWjpn3rs6t8RgxYSMnhe6akZe/S4FA7V6MCHlY5daLK6WmJjKdMzkyndACtaY92ZB ftZ4CgIhkeMm/6MHOwv9bf17+azLYv8= 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=Fz8H//fGCN/l/hW36Go9XyZtgnmMh++XjH8XbjFgENk=; b=TmVMfRupQEHtvU5PvRpVyyT+Mv VZ052z8n563fENDGzI5G2f0hTUy7oSC6VlgAzUwnfV6A5E/HOnKorARGwQML6dpm+a7rGbKb128dC Xtj1NHZU89Vgt/mbzGE8D7YcJSwQdI4QCsXTW0RkuamQEJpIEVm0AHXb/x9ra4wT9E9VEvgNVrQ8e zwSFtGxfNch9lF+oS+juzvV1EgviL6LDbQ/9foCo3TsZhVi8leOSd2VJVEcQChn6MWnSPkwIBCpPl 9Qxi7JMXgsS1PFppjGEPtI+FytnI1lRLNqw2m9CflDJpntAFtqalu0rVrF0ZvpR0IKCK9/AcphoUP HTgTGUfw==; Received: from willy by casper.infradead.org with local (Exim 4.94.2 #2 (Red Hat Linux)) id 1pP4QS-00GuSG-Hn; Mon, 06 Feb 2023 16:33:04 +0000 Date: Mon, 6 Feb 2023 16:33:04 +0000 From: Matthew Wilcox To: David Hildenbrand Cc: "Yin, Fengwei" , linux-mm@kvack.org, dave.hansen@intel.com, tim.c.chen@intel.com, ying.huang@intel.com Subject: Re: [RFC PATCH v4 3/4] mm: add do_set_pte_range() Message-ID: References: <20230206140639.538867-1-fengwei.yin@intel.com> <20230206140639.538867-4-fengwei.yin@intel.com> <7c8d3d2c-35e3-5be4-684b-4b991a0adb8e@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <7c8d3d2c-35e3-5be4-684b-4b991a0adb8e@redhat.com> X-Rspamd-Queue-Id: 53EF620025 X-Stat-Signature: 4741epx3r8yo91qfuw7cba8cfasz65dy X-Rspam-User: X-Rspamd-Server: rspam08 X-HE-Tag: 1675701191-169759 X-HE-Meta: U2FsdGVkX18lwU5RLDtFnvi15Dgv8eUOqD3DOh1m/a713mt+uWExTUZUTMaKUVKAXv91/An/tAuxghQ/kqXOhc3bramkTwP3apR/xOCaiV3JBmk//9P6Gq0xjecmv35GcVVBaQPvjt8wg+FpcO6iQOBWv3kf8OVfZq2lzFbxm4bXFi9diCZUnmBirY/yTddzaElwxrckgqkxCwW7ws4SOqz2L5rVKdYrrJHt0CWtYOdQJbkDa278iBykndxFd2telB1r41Gy4ktsPX+PUOTzMgZ4xIajmcGPxyCvx8FsYAcrKdJP7rBs61iOGNsAKD/csyJUTm742OnOKu4RBFI1uVUdpHAEY4MlFpfWTW+PZOOLTYsFlniI4/ls61hcvSDUZK8oshiiCiOTkFZiJRBdADbpal0cL8ZxK6vwy9V4Uree9s9HwnFo1VIpoaLTnDTYclK07mXTb+WoxOmyYm8cA+yUpjDK32hYAyZJINGP7z/XVsPEBtwV70Da6aZB8dgAKMOvEivWjHCZPNn3VHSi1mDkeqraCXUNx62pNEmCpSWs04eVs2bVqgMf9lQoqUHRpmMTBG9bbBO+XTl91YmWoUisEKBXF+EbGncAturxGKhG+nPDjHagFg89ib2LrTnVEsORyrw62GaNfnFEgujalRBObCN0dPVsfLhTp7kP2hG1MkyuN5Zqj90TYthxO8Ysf99gKlYUm3TLFFuzNVu310wfdI3Uq2sZGjgXy+6GJd8+Nh8eaTCyogMXgcyNCzVEkQwerrwdunTgR9T4Kl405iCf1KWVvO0ff6IHV7MO1hymiQAITxIIPHS075TJk00qNybl/mfYvkU2A18xKDqpf/ZkyFRqs+s2BvRnXANhWmLzFTUNVxxxoMtLADuIjvIgItSj738d73eGMeB3f0WjgIiZqR0vs6kvwAnJI3KhmZ1at37SG8vlUob8gBd52rmw/cEIglL4IQdsoguVsvm AzA6QKfb TrxpEze38pqALPqmBmjKWybtmPRzBpBlVzExkPnqVYzbu65T6dL7VSKkNmJG4C2muOwOKXre4AWaYeqfaV4W2RwIzl7FsEy0mUMMcWVI9YNoiNoetQaCQ0uq9h1uYfk6Tfz7IZpRFzp+w/RqY4kMveIBWX0IxsDZMMGxmyEdpNYDLCJVZBDs+pVN62pbmenEmKuUrGgV3ms9hEMs= 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 Mon, Feb 06, 2023 at 04:13:44PM +0100, David Hildenbrand wrote: > > > The handling of cow pages is still very clunky. > > > folio_add_new_anon_rmap() handles anonymous large folios just fine. I > > > think David was looking at current code, not the code in mm-next. > > OK. Let's wait for further comment from David. > > As I raised, page_add_new_anon_rmap() -> folio_add_new_anon_rmap() can be > used to add a fresh (a) PMD-mapped THP or (b) order-0 folio. > > folio_add_new_anon_rmap() is not suitable for PTE-mapping a large folio. > Which is what we are intending to do here unless I am completely off. I think you are. While the infrastructure here handles large folios which are not PMDs, there's nobody who will allocate such a thing, so there is no problem. Right> > PTE-mapping a large folio requires different accounting, different mapcount > handling and different PG_anon_exclusive handling. > > Which is all not there yet. Assuming you mean "a large folio which is not PMD sized", I agree. But we haven't even started discussing how we should decide to allocate folios which are not 0 or PMD order yet, so this worry seems premature. When we have figured that out, it'll be time to look at folio_add_new_anon_rmap() to decide how to support it, but hopefully before then we'll have a better way of handling mapcount.