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 77D02C433EF for ; Sat, 23 Oct 2021 22:23:43 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 05E5860F23 for ; Sat, 23 Oct 2021 22:23:42 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org 05E5860F23 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 43C3B6B006C; Sat, 23 Oct 2021 18:23:42 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 3EC876B0071; Sat, 23 Oct 2021 18:23:42 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 2B3CB940007; Sat, 23 Oct 2021 18:23:42 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0243.hostedemail.com [216.40.44.243]) by kanga.kvack.org (Postfix) with ESMTP id 190CE6B006C for ; Sat, 23 Oct 2021 18:23:42 -0400 (EDT) Received: from smtpin04.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay04.hostedemail.com (Postfix) with ESMTP id C1FEB39487 for ; Sat, 23 Oct 2021 22:23:41 +0000 (UTC) X-FDA: 78729130242.04.F88469F Received: from mail-qk1-f170.google.com (mail-qk1-f170.google.com [209.85.222.170]) by imf02.hostedemail.com (Postfix) with ESMTP id 77EA27001A23 for ; Sat, 23 Oct 2021 22:23:38 +0000 (UTC) Received: by mail-qk1-f170.google.com with SMTP id d205so8203763qke.3 for ; Sat, 23 Oct 2021 15:23:41 -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=/iY4mkP5CITw30ncTBqe0r7VHjZK/w2eKc4vTccqfLc=; b=gh/3JLk/ek1VRq0um4wQVJYOtNPOizsFL4Nyqh6Tkrr9ppVbg+rMXBdbaS7Dw0xdiJ VAMBHml6WguGG1oA8yCXyzmJRnSy068h356uvWaBmAruMb3a76LOKSI7zSwEqVme2NGP yG7eIDwPrZ1MlCeqltZI1Afp2HT7PNPFpg1Rzr3fZTMchPRMUrTwoqFgXinJ2ugXztgm oeCB+NzT/+snZeJ5CD8+zzFPqoVpArUaNM+JTIwKksWGKJzO6t2uyzHwXEMy11ZB/LmA w8Ls0Qh2lOo6fROGgwvtSCRukVUIsr8K3k/Su7aIRbW69wldtz5mFkfAdz7X6mSck0tu jH6g== 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=/iY4mkP5CITw30ncTBqe0r7VHjZK/w2eKc4vTccqfLc=; b=rgMd8J5zhkhITSIYRT82VTQWBv0GVMIjT3bD/JaCvxELxIM9tETBoffcLWI5ooTP5Z d+yzY3vXsHV3t4TL2tr6Gy4pqBNjQetHCrxBMdaFWVXst9OoVTLpIdrBnEwWFumFwtzB r932k3smPrcx8wuCWjs74OpGN2jVc5sErId6RVmeOW07TiuQEwyPE9nODwyDQNwH5HKO OmpvMFyS0nzPfXevB4hTgqgjZKUeCi8nAb4TyUccJ/NdHtrNjQ8VswibvYhg1VdO4kca CIOaA+raO3PvCcB5RVdr8jNTMT0Q72b3BagXRzIwHoRvq9wT/jUk+iZfuJ1/pDXsOPtv LlBg== X-Gm-Message-State: AOAM530qAiHThZ/+qxMjJs/LTRAKLtJUTo3OXLMMVSlNnvNnXyvI65q1 3puyiScGu0+JpJ+iPJNicA== X-Google-Smtp-Source: ABdhPJy1pkWM2MjtfxwtMIzluJqqKJiRCgDwA5NlxXOF6DHDGY0KNqcRRiBzHRc+/mnxrhyRPbgqHg== X-Received: by 2002:a05:620a:6bd:: with SMTP id i29mr6366027qkh.121.1635027820776; Sat, 23 Oct 2021 15:23:40 -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 k8sm6263868qkk.37.2021.10.23.15.23.38 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sat, 23 Oct 2021 15:23:39 -0700 (PDT) Date: Sat, 23 Oct 2021 18:23:37 -0400 From: Kent Overstreet To: Matthew Wilcox Cc: David Hildenbrand , 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: <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: X-Rspamd-Server: rspam05 X-Rspamd-Queue-Id: 77EA27001A23 X-Stat-Signature: 7s3zu6okugtkg7errynufdjdrxckhqug Authentication-Results: imf02.hostedemail.com; dkim=pass header.d=gmail.com header.s=20210112 header.b="gh/3JLk/"; spf=pass (imf02.hostedemail.com: domain of kent.overstreet@gmail.com designates 209.85.222.170 as permitted sender) smtp.mailfrom=kent.overstreet@gmail.com; dmarc=pass (policy=none) header.from=gmail.com X-HE-Tag: 1635027818-529890 X-Bogosity: Ham, tests=bogofilter, spamicity=0.001280, 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 10:41:41PM +0100, Matthew Wilcox wrote: > On Sat, Oct 23, 2021 at 12:00:38PM -0400, Kent Overstreet wrote: > > 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. > > I have a design in mind that I think avoids the problem. It's somewhat > based on Bonwick's vmem paper, but not exactly. I need to write it up. I am intruiged... Care to drop some hints? > Right. Folios are for unspecialised head pages. If we decide > to specialise further in the future, that's great! I think David > misunderstood me slightly; I don't know that specialising file + anon > pages (the aforementioned lru_mem) is the right approach. It might be! > But it needs someone to try it, and find the advantages & disadvantages. Well, that's where your current patches are basically headed, aren't they? As I understand it it's just file and some of the anon code that's converted so far. Are you thinking more along the lines of converting everything that can be mapped to userspace to folios? I think that would make a lot of sense given that converting the weird things to file pages isn't likely to happen any time soon, and it would us convert gup() to return folios, as Christoph noted. > > > 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... > > I'm happy to help. Indeed I may take on some of these sub-projects > myself. I just don't want the perfect to be the enemy of the good. Agreed!