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 mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id B1DC4C433F5 for ; Tue, 5 Oct 2021 13:54:45 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 672D76120D for ; Tue, 5 Oct 2021 13:54:45 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org 672D76120D Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=infradead.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=kvack.org Received: by kanga.kvack.org (Postfix) id F1B7E900002; Tue, 5 Oct 2021 09:54:44 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id ECB006B0071; Tue, 5 Oct 2021 09:54:44 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id D932E900002; Tue, 5 Oct 2021 09:54:44 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0229.hostedemail.com [216.40.44.229]) by kanga.kvack.org (Postfix) with ESMTP id AE3336B006C for ; Tue, 5 Oct 2021 09:54:44 -0400 (EDT) Received: from smtpin11.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay04.hostedemail.com (Postfix) with ESMTP id 6F8A527769 for ; Tue, 5 Oct 2021 13:54:44 +0000 (UTC) X-FDA: 78662529288.11.854B0B5 Received: from casper.infradead.org (casper.infradead.org [90.155.50.34]) by imf20.hostedemail.com (Postfix) with ESMTP id C78A3D00289E for ; Tue, 5 Oct 2021 13:54:43 +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=fPliqX+4y/fXYKkrPsdcJN5EsDLXmdXa3jrI3RxuZqo=; b=HWNkq0kUiHpUTPpZafcDeNnk43 lkwTkf/5ITfsDQOECQdIGNOHHYcRVdjV/7W4WGkVi9lmiM7NQkiG4vJL148Qg/kaLh1urI/5lFSy2 z5d2Ry0WkueUJLM80zgcGTQ9BR6Jr71tVs9UHjeHnn6YFLrEI9dApUnQVPajkltcj3+VWsvHNvGn7 kgkiPHsiY0DkUSROcMdMGdfYsDtu+8geX3OxcYJRpwtoEntkZf7c6vhTB+ww87EwDRgefqg0294kb 3Pv0wDaTD0pFucG/MuxqfjQedQMHHFECN2QrfQpzeTpsMzZgnbGKvc47H25ofF66k92entMll6Nbm OwCmf/dg==; Received: from willy by casper.infradead.org with local (Exim 4.94.2 #2 (Red Hat Linux)) id 1mXkrR-000VHF-9k; Tue, 05 Oct 2021 13:52:41 +0000 Date: Tue, 5 Oct 2021 14:52:01 +0100 From: Matthew Wilcox To: Johannes Weiner Cc: Linus Torvalds , linux-mm@kvack.org, linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org, Andrew Morton Subject: Re: [GIT PULL] Memory folios for v5.15 Message-ID: References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspamd-Server: rspam05 X-Rspamd-Queue-Id: C78A3D00289E X-Stat-Signature: 56zehj73nt4bznqbqsqwrmhut6f7eod3 Authentication-Results: imf20.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b=HWNkq0kU; dmarc=none; 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 X-HE-Tag: 1633442083-452216 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, Aug 23, 2021 at 05:26:41PM -0400, Johannes Weiner wrote: > One one hand, the ambition appears to substitute folio for everything > that could be a base page or a compound page even inside core MM > code. Since there are very few places in the MM code that expressly > deal with tail pages in the first place, this amounts to a conversion > of most MM code - including the LRU management, reclaim, rmap, > migrate, swap, page fault code etc. - away from "the page". > > However, this far exceeds the goal of a better mm-fs interface. And > the value proposition of a full MM-internal conversion, including > e.g. the less exposed anon page handling, is much more nebulous. It's > been proposed to leave anon pages out, but IMO to keep that direction > maintainable, the folio would have to be translated to a page quite > early when entering MM code, rather than propagating it inward, in > order to avoid huge, massively overlapping page and folio APIs. Here's an example where our current confusion between "any page" and "head page" at least produces confusing behaviour, if not an outright bug, isolate_migratepages_block(): page = pfn_to_page(low_pfn); ... if (PageCompound(page) && !cc->alloc_contig) { const unsigned int order = compound_order(page); if (likely(order < MAX_ORDER)) low_pfn += (1UL << order) - 1; goto isolate_fail; } compound_order() does not expect a tail page; it returns 0 unless it's a head page. I think what we actually want to do here is: if (!cc->alloc_contig) { struct page *head = compound_head(page); if (PageHead(head)) { const unsigned int order = compound_order(head); low_pfn |= (1UL << order) - 1; goto isolate_fail; } } Not earth-shattering; not even necessarily a bug. But it's an example of the way the code reads is different from how the code is executed, and that's potentially dangerous. Having a different type for tail and not-tail pages prevents the muddy thinking that can lead to tail pages being passed to compound_order().