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 ACF09C433F5 for ; Thu, 21 Oct 2021 13:00:16 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 5B6DB61186 for ; Thu, 21 Oct 2021 13:00:16 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org 5B6DB61186 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 BE829940007; Thu, 21 Oct 2021 09:00:15 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id B9731900004; Thu, 21 Oct 2021 09:00:15 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 9E9DF940007; Thu, 21 Oct 2021 09:00:15 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0136.hostedemail.com [216.40.44.136]) by kanga.kvack.org (Postfix) with ESMTP id 8E7F8900004 for ; Thu, 21 Oct 2021 09:00:15 -0400 (EDT) Received: from smtpin11.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay02.hostedemail.com (Postfix) with ESMTP id 498E131E5A for ; Thu, 21 Oct 2021 13:00:15 +0000 (UTC) X-FDA: 78720452790.11.A02BB5C 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 C43C3D042B73 for ; Thu, 21 Oct 2021 13:00:12 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1634821214; 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=FfLpJ3QKCtDn5mfQ0p/F6XAIE90YCmZunG7Z1kcvIk4=; b=gOtwez0ItPLbZ629t3iEjD7m6C9Fatuvui2Z5dfwwiK1frF366yjpAFsRtGKTUjSVwJafs h6rZ2uAZk+mQ4wg6Z2hRulJHJrqeQ9RG7Dod083zsrNxdcia5gSViUYdpQ5dOP2rGDHM04 shLN8nk0LYDBtiDfwQnSG4l6G0EUuTI= Received: from mail-wr1-f70.google.com (mail-wr1-f70.google.com [209.85.221.70]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-566-OyzmBHDhOLiICuGCC0xoLQ-1; Thu, 21 Oct 2021 09:00:13 -0400 X-MC-Unique: OyzmBHDhOLiICuGCC0xoLQ-1 Received: by mail-wr1-f70.google.com with SMTP id 41-20020adf802c000000b00161123698e0so147020wrk.12 for ; Thu, 21 Oct 2021 06:00:13 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:message-id:date:mime-version:user-agent :content-language:to:cc:references:from:organization:subject :in-reply-to:content-transfer-encoding; bh=FfLpJ3QKCtDn5mfQ0p/F6XAIE90YCmZunG7Z1kcvIk4=; b=MenrqDAJ3g6Ly0zkIcjIVmcjYfgtOU0FsTHkDSPa6uIhAOlRfgaPYSKdUkiLyCqeiG s9R2ElHRyP77owTxuGYV/PnbSiCJVY2P4FbBCGgu2hNobqih6PWjHlIo1UJ+50ulix4t yVjMLvjXM5+c2rzZr65s+nvRE9KjbgZrZk0sxzAHo3/2zF58M/vY0uRR7Njl5+GdKn4+ mVUSgWZvFX9ola5sojA2/bUrr0eoAZJ7GU/FjEb3YEmCPh9VxMgxMkDwR7udlJTHvQN/ PrEAz92jgzWNMaC/VAjNbXUFenGr9rGpEUfKa/c93Ix2oSNjiJGp6pkTKDrfG6032pCT Ak2g== X-Gm-Message-State: AOAM532AVdZ62jJdSUwiMKBwByJoegqbSh2dro8X/gquxzriaTmszN+o UFExZeuazw73hHI3RYcVK9qr60eFtaCHg6zAOcGEDVW9Emwixvft/0ZuDcYZh5GY9830pH9SMJs yUwLPhrPu4zQ= X-Received: by 2002:a7b:c31a:: with SMTP id k26mr5899042wmj.187.1634821211039; Thu, 21 Oct 2021 06:00:11 -0700 (PDT) X-Google-Smtp-Source: ABdhPJyg5aN7cYuw3+jxkmmX4w+oTRT02XFiIXsD9OlC+wd2uOLfvbi5+VSLG7UhWvkO/zaT9gJXkA== X-Received: by 2002:a7b:c31a:: with SMTP id k26mr5898985wmj.187.1634821210632; Thu, 21 Oct 2021 06:00:10 -0700 (PDT) Received: from [192.168.3.132] (p4ff23aba.dip0.t-ipconnect.de. [79.242.58.186]) by smtp.gmail.com with ESMTPSA id w2sm4851031wrt.31.2021.10.21.06.00.08 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 21 Oct 2021 06:00:10 -0700 (PDT) Message-ID: <90909355-43cd-e680-bb73-777d485ee532@redhat.com> Date: Thu, 21 Oct 2021 15:00:08 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.1.0 To: Christoph Hellwig Cc: Kent Overstreet , Matthew Wilcox , Johannes Weiner , "Kirill A. Shutemov" , Linus Torvalds , linux-mm@kvack.org, linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org, Andrew Morton , "Darrick J. Wong" , David Howells , Hugh Dickins References: <20211018231627.kqrnalsi74bgpoxu@box.shutemov.name> <996b3ac4-1536-2152-f947-aad6074b046a@redhat.com> <436a9f9c-d5af-7d12-b7d2-568e45ffe0a0@redhat.com> <2fc2c5da-c0e9-b954-ba48-e258b88e3271@redhat.com> From: David Hildenbrand Organization: Red Hat Subject: Re: Folios for 5.15 request - Was: re: Folio discussion recap - In-Reply-To: X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Language: en-US Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Stat-Signature: eurppqgrf8qe686swhyggccuhr6bxe1u X-Rspamd-Server: rspam01 X-Rspamd-Queue-Id: C43C3D042B73 Authentication-Results: imf21.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=gOtwez0I; 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: 1634821212-418519 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 21.10.21 14:38, Christoph Hellwig wrote: > On Thu, Oct 21, 2021 at 02:35:32PM +0200, David Hildenbrand wrote: >> My opinion after all the discussions: use a dedicate type with a clear >> name to solve the immediate filemap API issue. Leave the remainder alone >> for now. Less code to touch, less subsystems to involve (well, still a >> lot), less people to upset, less discussions to have, faster review, >> faster upstream, faster progress. A small but reasonable step. > > I don't get it. I mean I'm not the MM expert, I've only been touching > most areas of it occasionally for the last 20 years, but anon and file > pages have way more in common both in terms of use cases and You most certainly have way more MM expertise than me ;) I'm just a random MM developer, so everybody can feel free to just ignore what I'm saying here. I didn't NACK anything, I just consider a lot of things that Johannes raised reasonable. > implementation than what is different (unlike some of the other (ab)uses > of struct page). What is the point of splitting it now when there are > tons of use cases where they are used absolutely interchangable both > in consumers of the API and the implementation? I guess in an ideal world, we'd have multiple abstractions. We could clearly express for a function what type it expects. We'd have a type for something passed on the filemap API. We'd have a type for anon THP (or even just an anon page). We'd have a type that abstracts both. With that in mind, and not planning with what we'll actually end up with, to me it makes perfect sense to teach the filemap API to consume the expected type first. And I am not convinced that the folio as is ("not a tail page") is the right abstraction we actually want to pass around in places where we expect either anon or file pages -- or only anon pages or only file pages. Again, my 2 cents. -- Thanks, David / dhildenb