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 68844C433F5 for ; Tue, 5 Oct 2021 17:33:05 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id EB4AB613D5 for ; Tue, 5 Oct 2021 17:33:04 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org EB4AB613D5 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=redhat.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=kvack.org Received: by kanga.kvack.org (Postfix) id 487606B006C; Tue, 5 Oct 2021 13:33:04 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 436BD6B0071; Tue, 5 Oct 2021 13:33:04 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 3247B6B0073; Tue, 5 Oct 2021 13:33:04 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0145.hostedemail.com [216.40.44.145]) by kanga.kvack.org (Postfix) with ESMTP id 264AE6B006C for ; Tue, 5 Oct 2021 13:33:04 -0400 (EDT) Received: from smtpin40.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay03.hostedemail.com (Postfix) with ESMTP id D78CF82499A8 for ; Tue, 5 Oct 2021 17:33:03 +0000 (UTC) X-FDA: 78663079446.40.7C91211 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by imf21.hostedemail.com (Postfix) with ESMTP id 76452D03A0CD for ; Tue, 5 Oct 2021 17:33:03 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1633455183; h=from:from: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:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=DGNbaD457msJgVdKh0PPRgk92evjmql7WYFpgopbLNQ=; b=iNtxNIuq9bP8NpJzCbGZ0qLSc+M3g+0QxPUplxfCYLjImv7VPiG0DeLngrpKMYpzYgJa7c I5qtN59cq6DM3Gb4tWpjr82Bima/FLE5Pbm/nGmOcydQpAC72CDW0v996Yk2lJnd4iX6GZ zdglUiHzcXG/OpBweWYDnah0ceJ1Whk= Received: from mail-wm1-f70.google.com (mail-wm1-f70.google.com [209.85.128.70]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-368-9cXnpPabOouUd65btdHeGg-1; Tue, 05 Oct 2021 13:33:02 -0400 X-MC-Unique: 9cXnpPabOouUd65btdHeGg-1 Received: by mail-wm1-f70.google.com with SMTP id d7-20020a1c7307000000b0030d6982305bso1607084wmb.5 for ; Tue, 05 Oct 2021 10:33:01 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:subject:to:cc:references:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=DGNbaD457msJgVdKh0PPRgk92evjmql7WYFpgopbLNQ=; b=nabErhPXlicm1JgyB6ANhTq7ru+DAA3Q2Pv0NAq8/FFBtOpG26shCVpZHDDsLw2RHJ bkNqXR6LHvbvhqGZzptPZc8ZqpofO7MAh3x1hdBvTmGGNCydONU7pmHMHKdU5LEhh1jF k12Y6IqjpI0dvegJGsHkq3AJkFgH1oQ3NR8ppj6n3v5MwXH7bHaLC7Rs/qgBd+x9huq2 BWYEcSh2KxbG+4YdBeNTxuM/otDtaxTwcHEdrdIC3ECbgoHGAD1cxuX6aJtEYtw8xogp mG5674rNzDl+R32wnVn32rAhe2AVLnJ5V2YSq/hPfGj1NOyMt0JUez1WCNmOueJY7pzB H1bw== X-Gm-Message-State: AOAM530ONrZ3W27r4aeXcEWxMqx37S1Gv7uzoXKghWeoshsjWo58pp0U Nn6bQoZLoHv+i7NWF7gE5dJdLMZNqtiF52rjoNzB3WABGBkf5+q4fvCIaujnRZsCDnqapiHPZeg JX5CmI/ozWtA= X-Received: by 2002:a05:600c:19d0:: with SMTP id u16mr4937371wmq.154.1633455180746; Tue, 05 Oct 2021 10:33:00 -0700 (PDT) X-Google-Smtp-Source: ABdhPJxK5P/yoc8rNM3rXntf+k70Y2v/zMNddpcdV9cSYPP4ViHxZlYT7fhz5Hy7rnFKdBkGsYmjpA== X-Received: by 2002:a05:600c:19d0:: with SMTP id u16mr4937342wmq.154.1633455180492; Tue, 05 Oct 2021 10:33:00 -0700 (PDT) Received: from [192.168.3.132] (p5b0c6741.dip0.t-ipconnect.de. [91.12.103.65]) by smtp.gmail.com with ESMTPSA id o3sm18358930wra.52.2021.10.05.10.32.59 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 05 Oct 2021 10:33:00 -0700 (PDT) Subject: Re: [GIT PULL] Memory folios for v5.15 To: Johannes Weiner , Matthew Wilcox Cc: Linus Torvalds , linux-mm@kvack.org, linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org, Andrew Morton References: From: David Hildenbrand Organization: Red Hat Message-ID: Date: Tue, 5 Oct 2021 19:32:59 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.11.0 MIME-Version: 1.0 In-Reply-To: X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Rspamd-Server: rspam01 X-Rspamd-Queue-Id: 76452D03A0CD X-Stat-Signature: bem4bp1359pbzbdybhpit1hfa75jjmhe Authentication-Results: imf21.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=iNtxNIuq; dmarc=pass (policy=none) header.from=redhat.com; spf=none (imf21.hostedemail.com: domain of david@redhat.com has no SPF policy when checking 170.10.133.124) smtp.mailfrom=david@redhat.com X-HE-Tag: 1633455183-693749 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 05.10.21 19:29, Johannes Weiner wrote: > On Tue, Oct 05, 2021 at 02:52:01PM +0100, Matthew Wilcox wrote: >> 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(). > > Thanks for digging this up. I agree the second version is much better. > > My question is still whether the extensive folio whitelisting of > everybody else is the best way to bring those codepaths to light. > > The above isn't totally random. That code is a pfn walker which > translates from the basepage address space to an ambiguous struct page > object. There are more of those, but we can easily identify them: all > uses of pfn_to_page() and virt_to_page() indicate that the code needs > an audit for how exactly they're using the returned page. +pfn_to_online_page() -- Thanks, David / dhildenb