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 280B9C433F5 for ; Wed, 20 Oct 2021 07:51:05 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id AEBAB61A7C for ; Wed, 20 Oct 2021 07:51:04 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org AEBAB61A7C 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 36A1F900002; Wed, 20 Oct 2021 03:51:04 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 31A116B0074; Wed, 20 Oct 2021 03:51:04 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 1E112900002; Wed, 20 Oct 2021 03:51:04 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0113.hostedemail.com [216.40.44.113]) by kanga.kvack.org (Postfix) with ESMTP id 0B3146B0073 for ; Wed, 20 Oct 2021 03:51:04 -0400 (EDT) Received: from smtpin10.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay04.hostedemail.com (Postfix) with ESMTP id 6E4C825F24 for ; Wed, 20 Oct 2021 07:51:03 +0000 (UTC) X-FDA: 78716044806.10.3FAF667 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [216.205.24.124]) by imf24.hostedemail.com (Postfix) with ESMTP id 6DAC1B00009D for ; Wed, 20 Oct 2021 07:51:00 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1634716262; 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=aj7Vb0KWV79M1QnYKnvPwJppFiYy0tbNTL9fv9yVSsk=; b=M6uVziQxbQzoe5qfRDj6TRt+Y/Ln4ijmJIFA1jlg3WyasP1lc7OEYq6Hqk/0aSWGjRwHoG tWEYerXPtL6miUE710uRVXhyHkIQEdf2cFOGH4yBcjUxmCoWj1EkBEqbn6G51ucEJ/rHBx 5BTa1guDs/jx3ikWkO4fZQ8l4QhiixU= Received: from mail-wm1-f71.google.com (mail-wm1-f71.google.com [209.85.128.71]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-563-aCarBwPaPROZii-fph8JPA-1; Wed, 20 Oct 2021 03:51:01 -0400 X-MC-Unique: aCarBwPaPROZii-fph8JPA-1 Received: by mail-wm1-f71.google.com with SMTP id p12-20020a05600c204c00b0030da46b76daso2147685wmg.9 for ; Wed, 20 Oct 2021 00:51: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:message-id:date:mime-version:user-agent :content-language:to:cc:references:from:organization:subject :in-reply-to:content-transfer-encoding; bh=aj7Vb0KWV79M1QnYKnvPwJppFiYy0tbNTL9fv9yVSsk=; b=1OPZq9Ory8mkZaQfQZnye8DuHEUVJvw3DKYTAnwc8KpjK3CFL16botvwtf8Mi9vf3w 9n7HfLyY2oB9dlAi6j3z+Hce9Orrog3Sb/Ox345L8S8+VjVNq+w2AY9GE+aC3kAFL0xy h8JFnzxhISL2QNU87pt4oK634LEepb4gYEQsJMF8dpoaFiGXUH9rN6196Wr5QeQ0q3Qv UhffD99LOxeWDKHMt3iLS5BoR5Qa1d1Fvp7oL92+YI5r3mol3T0F61I4cjjK8BVVjGhP S4eM5d0env8W7HethOgtxYXgzdRjexHiGPspAltvyRU/QIatrkRTEfslx4gUQiUQNW0A sdSw== X-Gm-Message-State: AOAM530ApvmTqbls1qJpKlKyNw8Ryn/9kS5flpPjzvrcoWzABU9tKDt2 lCK46LsU8CS52xum1SHkPhyY3tibWtjwDls8v+GTkzApX4NU7lit3AJWfEdrTj2agXmU1UVQXbN Tgxl+hoJOnEs= X-Received: by 2002:adf:a118:: with SMTP id o24mr49827661wro.15.1634716260019; Wed, 20 Oct 2021 00:51:00 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwXElaXdSpOfBhp+HWj7pfjq41epCfv+2QQ/z2gNb0CvANLqwz4gZXGZKmv6SSMRfA6RszSRw== X-Received: by 2002:adf:a118:: with SMTP id o24mr49827630wro.15.1634716259710; Wed, 20 Oct 2021 00:50:59 -0700 (PDT) Received: from [192.168.3.132] (p5b0c63d4.dip0.t-ipconnect.de. [91.12.99.212]) by smtp.gmail.com with ESMTPSA id t4sm1261277wro.1.2021.10.20.00.50.58 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 20 Oct 2021 00:50:59 -0700 (PDT) Message-ID: <996b3ac4-1536-2152-f947-aad6074b046a@redhat.com> Date: Wed, 20 Oct 2021 09:50:58 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.1.0 To: Johannes Weiner , "Kirill A. Shutemov" Cc: Matthew Wilcox , Kent Overstreet , Linus Torvalds , linux-mm@kvack.org, linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org, Andrew Morton , "Darrick J. Wong" , Christoph Hellwig , David Howells , Hugh Dickins References: <20211018231627.kqrnalsi74bgpoxu@box.shutemov.name> 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 Authentication-Results: imf24.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=M6uVziQx; dmarc=pass (policy=none) header.from=redhat.com; spf=none (imf24.hostedemail.com: domain of david@redhat.com has no SPF policy when checking 216.205.24.124) smtp.mailfrom=david@redhat.com X-Rspamd-Server: rspam03 X-Rspamd-Queue-Id: 6DAC1B00009D X-Stat-Signature: dr7b9nmjoykakm6du3xc41kgcgcg1d9t X-HE-Tag: 1634716260-872282 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 19.10.21 17:16, Johannes Weiner wrote: > On Tue, Oct 19, 2021 at 02:16:27AM +0300, Kirill A. Shutemov wrote: >> On Mon, Oct 18, 2021 at 05:56:34PM -0400, Johannes Weiner wrote: >>>> I don't think there will ever be consensus as long as you don't take >>>> the concerns of other MM developers seriously. On Friday's call, several >>>> people working on using large pages for anon memory told you that using >>>> folios for anon memory would make their lives easier, and you didn't care. >>> >>> Nope, one person claimed that it would help, and I asked how. Not >>> because I'm against typesafety, but because I wanted to know if there >>> is an aspect in there that would specifically benefit from a shared >>> folio type. I don't remember there being one, and I'm not against type >>> safety for anon pages. >>> >>> What several people *did* say at this meeting was whether you could >>> drop the anon stuff for now until we have consensus. >> >> My read on the meeting was that most of people had nothing against anon >> stuff, but asked if Willy could drop anon parts to get past your >> objections to move forward. >> >> You was the only person who was vocal against including anon pars. (Hugh >> nodded to some of your points, but I don't really know his position on >> folios in general and anon stuff in particular). > > Nobody likes to be the crazy person on the soapbox, so I asked Hugh in > private a few weeks back. Quoting him, with permission: > > : To the first and second order of approximation, you have been > : speaking for me: but in a much more informed and constructive and > : coherent and rational way than I would have managed myself. > > It's a broad and open-ended proposal with far reaching consequences, > and not everybody has the time (or foolhardiness) to engage on that. I > wouldn't count silence as approval - just like I don't see approval as > a sign that a person took a hard look at all the implications. > > My only effort from the start has been working out unanswered > questions in this proposal: Are compound pages the reliable, scalable, > and memory-efficient way to do bigger page sizes? What's the scope of > remaining tailpages where typesafety will continue to lack? How do we > implement code and properties shared by folios and non-folio types > (like mmap/fault code for folio and network and driver pages)? > > There are no satisfying answers to any of these questions, but that > also isn't very surprising: it's a huge scope. Lack of answers isn't > failure, it's just a sign that the step size is too large and too > dependent on a speculative future. It would have been great to whittle > things down to a more incremental and concrete first step, which would > have allowed us to keep testing the project against reality as we go > through all the myriad of uses and cornercases of struct page that no > single person can keep straight in their head. > > I'm grateful for the struct slab spinoff, I think it's exactly all of > the above. I'm in full support of it and have dedicated time, effort > and patches to help work out kinks that immediately and inevitably > surfaced around the slab<->page boundary. > > I only hoped we could do the same for file pages first, learn from > that, and then do anon pages; if they come out looking the same in the > process, a unified folio would be a great trailing refactoring step. > > But alas here we are months later at the same impasse with the same > open questions, and still talking in circles about speculative code. > I don't have more time to invest into this, and I'm tired of the > vitriol and ad-hominems both in public and in private channels. Thanks Johannes for defending your position and I can understand that you are running out of motivation+energy to defend further. For the records: I was happy to see the slab refactoring, although I raised some points regarding how to access properties that belong into the "struct page". As raised elsewhere, I'd also be more comfortable seeing small incremental changes/cleanups that are consistent even without having decided on an ultimate end-goal -- this includes folios. I'd be happy to see file-backed THP gaining their own, dedicated type first ("struct $whatever"), before generalizing it to folios. I'm writing this message solely to back your "not everybody has the time (or foolhardiness) to engage on that. I wouldn't count silence as approval.". While I do have the capacity to review smaller, incremental steps (see struct slab), I don't have the time+energy to gasp the full folio picture. So I also second "it's a huge scope. [...] it's just a sign that the step size is too large and too dependent on a speculative future." My 2 cents on this topic. -- Thanks, David / dhildenb