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 0AAF1C433FE for ; Sat, 23 Oct 2021 16:00:47 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 76B6E60F9C for ; Sat, 23 Oct 2021 16:00:46 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org 76B6E60F9C Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=gmail.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=kvack.org Received: by kanga.kvack.org (Postfix) id 9EA9E940008; Sat, 23 Oct 2021 12:00:45 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 99A39940007; Sat, 23 Oct 2021 12:00:45 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 81345940008; Sat, 23 Oct 2021 12:00:45 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0133.hostedemail.com [216.40.44.133]) by kanga.kvack.org (Postfix) with ESMTP id 734A0940007 for ; Sat, 23 Oct 2021 12:00:45 -0400 (EDT) Received: from smtpin22.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay04.hostedemail.com (Postfix) with ESMTP id 2452632068 for ; Sat, 23 Oct 2021 16:00:45 +0000 (UTC) X-FDA: 78728165250.22.E1DC847 Received: from mail-qk1-f169.google.com (mail-qk1-f169.google.com [209.85.222.169]) by imf18.hostedemail.com (Postfix) with ESMTP id A359E40020A7 for ; Sat, 23 Oct 2021 16:00:44 +0000 (UTC) Received: by mail-qk1-f169.google.com with SMTP id d15so7439441qkj.10 for ; Sat, 23 Oct 2021 09:00:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=qthr8cU1dSojgOgBBt4dT5UmFwa8J4R/24qOs7tEfOI=; b=SW1HV4z3DDfn8pj9XE8+R6qNKJBkLTktSvZMfr3j+nyDqEl7eJIklPbA+ioEgkktQd mBQMpVdA54dqQlvh/RSq/nBqQnxquZjFkCaGvAop64ZyB+SA9DQJ7Z1IZS9AAB2qgrYk SMNEhTXuYVqZfGgdV4xt4hpbLJ6xY0WE6ZKGmUJJoTD2fONrNV6J9gHfT6cCLtjFOzBj RRVVu6SVPDgbPydliOdQ/EqV0gnwk3NjRjjnI3p10GSWyY2ZW2xUhjItslmja+o4/l15 DuRRf7Fv03S785KppBZUOBOz6Cyt3PHYmanBztu9fmoocLXhyvEZ8Rlpbgy/KGNzfK7n OI9A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=qthr8cU1dSojgOgBBt4dT5UmFwa8J4R/24qOs7tEfOI=; b=02kXI+hsLzCAAM6D6rKGLe5+TUE0cyNVtgnlKKmOLe4usD+2gwciEbk3Tt1E9BHKD2 7nw+0e/NiWwz7BfK5Iw60PPstHMsLrwrPkVRBGz2rViMwAvwarq0qChSrH2VMylyH8xT 91ucc0KiD9P6Tr0O/D95Dw2wdyZ1kxU/W1uTPZWLMhb4Mmn1rE2PkoRUrBT+N5cuuZFZ RRTnnMDHaQ0THJy7FpezLVl/mb06LKtzqvY28ywPf9drhHDSVd6VwHlWQdsI2XWv+EcS AgDBcEfXQPpPtV/PQ10L5xxzdnZLBCRKkFUltkWEgC/dyoxI1sQPrmQ9NkmBkiUz7atc qF+g== X-Gm-Message-State: AOAM531bE1CJE2EPOCx1GvAFJU/tjUbBbugof/0/x4xgBfrCbgSLeWV5 fKzP9AJSJSbW+m1rJZ5biQ== X-Google-Smtp-Source: ABdhPJwOt99lzC+F3f94YhOfmD9szqqqxLxeUc+99UfI57we1FBO952e676doMC29RdKHILlnaJK9Q== X-Received: by 2002:a37:44c8:: with SMTP id r191mr5372123qka.507.1635004843919; Sat, 23 Oct 2021 09:00:43 -0700 (PDT) Received: from moria.home.lan (c-73-219-103-14.hsd1.vt.comcast.net. [73.219.103.14]) by smtp.gmail.com with ESMTPSA id m28sm5835578qkm.23.2021.10.23.09.00.42 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sat, 23 Oct 2021 09:00:42 -0700 (PDT) Date: Sat, 23 Oct 2021 12:00:38 -0400 From: Kent Overstreet To: David Hildenbrand Cc: 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" , Christoph Hellwig , David Howells , Hugh Dickins Subject: Re: Folios for 5.15 request - Was: re: Folio discussion recap - Message-ID: References: <20211018231627.kqrnalsi74bgpoxu@box.shutemov.name> <326b5796-6ef9-a08f-a671-4da4b04a2b4f@redhat.com> <404bdc05-487f-3d47-6b30-0687b74c2f2f@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <404bdc05-487f-3d47-6b30-0687b74c2f2f@redhat.com> X-Rspamd-Queue-Id: A359E40020A7 Authentication-Results: imf18.hostedemail.com; dkim=pass header.d=gmail.com header.s=20210112 header.b=SW1HV4z3; spf=pass (imf18.hostedemail.com: domain of kent.overstreet@gmail.com designates 209.85.222.169 as permitted sender) smtp.mailfrom=kent.overstreet@gmail.com; dmarc=pass (policy=none) header.from=gmail.com X-Stat-Signature: d6y66xm3qqa7acq1zd7iaehbjicqzjsr X-Rspamd-Server: rspam06 X-HE-Tag: 1635004844-988780 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 Sat, Oct 23, 2021 at 11:58:42AM +0200, David Hildenbrand wrote: > I know, the crowd is screaming "we want folios, we need folios, get out > of the way". I know that the *compound page* handling is a mess and that > we want something to change that. The point I am making is that folios > are not necessarily what we *need*. > > Types as discussed above are really just using the basic idea of a folio > lifted to the next level that not only avoid any kind of PageTail checks > but also any kind of type checks we have splattered all over the place. > IMHO that's a huge win when it comes to code readability and > maintainability. This also tackles the point Johannes made: folios being > the dumping ground for everything. And he has a point, because folios > are really just "not tail pages", so consequently they will 99% just > mimic what "struct page" does, and we all know what that means. Look, even if folios go this direction of being the compound page replacement, the "new dumping ground" argument is just completely bogus. In introducing new types and type safety for struct page, it's not reasonable to try to solve everything at once - we don't know what an ideal end solution is going to look like, we can't see that far ahead. What is a reasonable approach is looking for where the fault lines in the way struct page is used now, and cutting along those lines, look at the result, then cut it up some more. If the first new type still inherits most of the mess in struct page but it solves real problems, that's not a failure, that's normal incremental progress! -------- More than that, I think you and Johannes heard what I was saying about imagining what the ideal end solution would look like with infinite refactoring and you two have been running way too far with that idea - the stuff you guys are talking about sounds overengineered to me - inheritence heirarchies before we've introduced the first new type! The point of such thought experiments is to imagine how simple things could be - and also to not take such thought experiments too seriously, because when we start refactoring real world code, that's when we discover what's actually _possible_. I ran into a major roadblock when I tried converting buddy allocator freelists to radix trees: freeing a page may require allocating a new page for the radix tree freelist, which is fine normally - we're freeing a page after all - but not if it's highmem. So right now I'm not sure if getting struct page down to two words is even possible. Oh well. > Your patches introduce the concept of folio across many layers and your > point is to eventually clean up later and eventually remove it from all > layers again. I can understand that approach, yet I am at least asking > the question if this is the right order to do this. > > And again, I am not blocking this, I think cleaning up compound pages is > very nice. I'm asking questions to see how the concept of folios would > fit in long-term and if it would be required at all if types are done right. I'm also not really seeing the need to introduce folios as a replacement for all of compound pages, though - I think limiting it to file & anon and using the union-of-structs in struct page as the fault lines for introducing new types would be the reasonable thing to do. The struct slab patches were great, it's a real shame that the slab maintainers have been completely absent. Also introducing new types to be describing our current using of struct page isn't the only thing we should be doing - as we do that, that will (is!) uncover a lot of places where our ontology of struct page uses is just nonsensical (all the types of pages mapped into userspace!) - and part of our mission should be to clean those up. That does turn things into a much bigger project than what Matthew signed up for, but we shouldn't all be sitting on the sidelines here...