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 500D9C433EF for ; Wed, 13 Apr 2022 12:49:22 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id AB6B46B0072; Wed, 13 Apr 2022 08:49:21 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id A648D6B0073; Wed, 13 Apr 2022 08:49:21 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 92C9F6B0074; Wed, 13 Apr 2022 08:49:21 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0188.hostedemail.com [216.40.44.188]) by kanga.kvack.org (Postfix) with ESMTP id 80EAD6B0072 for ; Wed, 13 Apr 2022 08:49:21 -0400 (EDT) Received: from smtpin30.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay04.hostedemail.com (Postfix) with ESMTP id 1983DAA099 for ; Wed, 13 Apr 2022 12:49:21 +0000 (UTC) X-FDA: 79351836522.30.85862A7 Received: from casper.infradead.org (casper.infradead.org [90.155.50.34]) by imf20.hostedemail.com (Postfix) with ESMTP id 8B5701C0004 for ; Wed, 13 Apr 2022 12:49:20 +0000 (UTC) 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=RGbYhpXywzqv2Hlc31WFYOQppwWEQngmyLOiz4SPLMc=; b=o/CdrJdGaOo/+UkTwXEgHYmTJ5 TVDAF0tewzHLjCwR6q5XktVPi6We1u9p2XdJdoEWxcJXOUD6QlalIPEHhsY4pFuo1I4Oqu9+w/0L6 V/ijAASP/ARnuJDM9SbL3HymUp+TUOx4vwezAmiO810NhKDdC7dJdWBl+d8JmEKxTFyOQ4lOcHRXr DUbbSHtl7FuohRtOQiEuaS5GhB+CmKXTKAryFnwf8rK84K5hSe03bQl+XI2BbAPaxUyUFl24kVmow vEa4bVOlYg8AoYVAu274c8U5DjhowWcVgGl4DY77ae/2Ez54zo9nfeoXx97v7R9tCAQ/fnVPhQugF xuTmCaTQ==; Received: from willy by casper.infradead.org with local (Exim 4.94.2 #2 (Red Hat Linux)) id 1necQV-00EGJp-Iq; Wed, 13 Apr 2022 12:48:51 +0000 Date: Wed, 13 Apr 2022 13:48:51 +0100 From: Matthew Wilcox To: David Hildenbrand Cc: Vlastimil Babka , linux-kernel@vger.kernel.org, Andrew Morton , Hugh Dickins , Linus Torvalds , David Rientjes , Shakeel Butt , John Hubbard , Jason Gunthorpe , Mike Kravetz , Mike Rapoport , Yang Shi , "Kirill A . Shutemov" , Jann Horn , Michal Hocko , Nadav Amit , Rik van Riel , Roman Gushchin , Andrea Arcangeli , Peter Xu , Donald Dutile , Christoph Hellwig , Oleg Nesterov , Jan Kara , Liang Zhang , Pedro Gomes , Oded Gabbay , linux-mm@kvack.org Subject: Re: [PATCH v3 08/16] mm/rmap: drop "compound" parameter from page_add_new_anon_rmap() Message-ID: References: <20220329160440.193848-1-david@redhat.com> <20220329160440.193848-9-david@redhat.com> <4cb92b41-95e1-1666-321e-96ff9e6095bb@suse.cz> <368902ab-8d3f-5d62-581e-1ff930bcefa0@redhat.com> <0c9d2c39-5080-a855-8ecd-e2c1bd1179fa@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <0c9d2c39-5080-a855-8ecd-e2c1bd1179fa@redhat.com> Authentication-Results: imf20.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b="o/CdrJdG"; spf=none (imf20.hostedemail.com: domain of willy@infradead.org has no SPF policy when checking 90.155.50.34) smtp.mailfrom=willy@infradead.org; dmarc=none X-Stat-Signature: c8zznqwo7zfxuc8a49gocmh3h418mxuq X-Rspam-User: X-Rspamd-Server: rspam12 X-Rspamd-Queue-Id: 8B5701C0004 X-HE-Tag: 1649854160-335237 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, Apr 13, 2022 at 02:28:38PM +0200, David Hildenbrand wrote: > On 13.04.22 14:26, Matthew Wilcox wrote: > > On Tue, Apr 12, 2022 at 11:37:09AM +0200, David Hildenbrand wrote: > >> On 12.04.22 10:47, Vlastimil Babka wrote: > >>> There's a VM_BUG_ON_PAGE(PageTransCompound(page), page); later in a > >>> !compound branch. Since compound is now determined by the same check, could > >>> be deleted. > >> > >> Yes, eventually we could get rid of both VM_BUG_ON_PAGE() on both > >> branches and add a single VM_BUG_ON_PAGE(PageTail(page), page) check on > >> the compound branch. (we could also make sure that we're not given a > >> hugetlb page) > > > > As a rule of thumb, if you find yourself wanting to add > > VM_BUG_ON_PAGE(PageTail(page), page), you probably want to change the > > interface to take a folio. > > Yeah, I had the same in mind. Might be a reasonable addon on top -- > although it would stick out in the rmap code a bit because most > functions deal with both, folios and subpages. I have the start of a series which starts looking at the fault path to see where it makes sense to use folios and where it makes sense to use pages. We're (generally) faulting on a PTE, so we need the precise page to be returned in vmf->page. However vmf->cow_page can/should be a folio (because it's definitely not a tail page). That trickles down into copy_present_page() (new_page and prealloc both become folios) and so page_add_new_anon_rmap() then looks like a good target to take a folio. The finish_fault() -> do_set_pte() -> page_add_new_anon_rmap() looks like the only kind of strange place where we don't necessarily have a folio (all the others we just allocated it).