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 X-Spam-Level: X-Spam-Status: No, score=-3.8 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id A63A4C432BE for ; Fri, 27 Aug 2021 10:01:44 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 25BBD60ED5 for ; Fri, 27 Aug 2021 10:01:44 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org 25BBD60ED5 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=cmpxchg.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=kvack.org Received: by kanga.kvack.org (Postfix) id A15D38D0002; Fri, 27 Aug 2021 06:01:43 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 9C59D8D0001; Fri, 27 Aug 2021 06:01:43 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 8B58C8D0002; Fri, 27 Aug 2021 06:01:43 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0097.hostedemail.com [216.40.44.97]) by kanga.kvack.org (Postfix) with ESMTP id 6E7318D0001 for ; Fri, 27 Aug 2021 06:01:43 -0400 (EDT) Received: from smtpin22.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay05.hostedemail.com (Postfix) with ESMTP id 0EB8E1838F82A for ; Fri, 27 Aug 2021 10:01:43 +0000 (UTC) X-FDA: 78520418886.22.9770216 Received: from mail-qt1-f173.google.com (mail-qt1-f173.google.com [209.85.160.173]) by imf23.hostedemail.com (Postfix) with ESMTP id 93CF590000BC for ; Fri, 27 Aug 2021 10:01:42 +0000 (UTC) Received: by mail-qt1-f173.google.com with SMTP id t32so4876955qtc.3 for ; Fri, 27 Aug 2021 03:01:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cmpxchg-org.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=rQfDhKdyv4fg+r/Y8tJRlauQXOHaMeoAScvmzQy4FHs=; b=RTLv6h70dh2KQII/tDH9L9yJ8miO9zpfOpvNplcUXADClA/t4d04/dUTNNJuQ3shw7 cizitKFTo0u79Z/fmo8Ln2MzW97bK94RB1e0dJizK4fFMqJTyT1WYhAiMn6IIshUXs3p NBvDuATr9/eQf0W6A8AsuNdaLBwYcklIw9yWyR5a9Dj90sit/Oa4s2DBKB9XcaJyj3X9 tfzrB1/Rqbb2/O8RwETIUQVk9gSJ2brJd9NkuFvst0k7e1vSxkdoqC+jEz7KI691SSv9 pJqiEDWUJI5KjpFTHzOkrKEWPpUebnJ/6n6TJrckDM/JI2+cwSxa0AAmXl3iSIUoj7fm PUFA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=rQfDhKdyv4fg+r/Y8tJRlauQXOHaMeoAScvmzQy4FHs=; b=b0SCxKseFRCkjg8k1MiM9lPz3Krl1EZp0Dw6Nx/wKyx24GsIVmknxH/Mt+ZrR8d2I8 /6UyQwY3gOri/aF8RMEiCjsUTzr6Q6sgeKyHq8juALlSQ6NVszQU8B0/yFcd6MtTu+x+ Z/Iz46gab4+M9MKHICCVUUPGnAnxjkW+dKp0iIny3wXOKbQnz7A73JRnJErr1oUYVmCQ ucwV2+8sm75nVEFO7JvV08TgttYIjVo86qkFPpMiX1iyQ39f36vdqU30c04rO7qd/zV2 UFrE/LHWzptcTkutrDdo4LcmwOaAduwN3g1XBMVH2clgjXz3qFbSzwiA2KCr9yA+r2Ut uDRg== X-Gm-Message-State: AOAM532VdL5TdFxjq1yNuDPUDYcms3fYDVah9AdR4l4HbvkD5iuZdLEy aWMWwanXP5IPePcugxn1a3T/3g== X-Google-Smtp-Source: ABdhPJxruXx9GN4mVk4E4paeBiocZ9oJrlEkYPFAGDlecOWvONIdfZd+D1u3UtfMc1kCEo/fHEq7pw== X-Received: by 2002:a05:622a:13d3:: with SMTP id p19mr3218319qtk.61.1630058501778; Fri, 27 Aug 2021 03:01:41 -0700 (PDT) Received: from localhost (cpe-98-15-154-102.hvc.res.rr.com. [98.15.154.102]) by smtp.gmail.com with ESMTPSA id c11sm3330069qth.29.2021.08.27.03.01.40 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 27 Aug 2021 03:01:40 -0700 (PDT) Date: Fri, 27 Aug 2021 06:03:25 -0400 From: Johannes Weiner To: David Howells Cc: Matthew Wilcox , Linus Torvalds , linux-mm@kvack.org, linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org, Andrew Morton Subject: Re: [GIT PULL] Memory folios for v5.15 Message-ID: References: <2101397.1629968286@warthog.procyon.org.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <2101397.1629968286@warthog.procyon.org.uk> Authentication-Results: imf23.hostedemail.com; dkim=pass header.d=cmpxchg-org.20150623.gappssmtp.com header.s=20150623 header.b=RTLv6h70; dmarc=pass (policy=none) header.from=cmpxchg.org; spf=pass (imf23.hostedemail.com: domain of hannes@cmpxchg.org designates 209.85.160.173 as permitted sender) smtp.mailfrom=hannes@cmpxchg.org X-Rspamd-Server: rspam06 X-Rspamd-Queue-Id: 93CF590000BC X-Stat-Signature: ajuub7quedkfkp3k453dzg6pxio8c6cy X-HE-Tag: 1630058502-90852 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 Thu, Aug 26, 2021 at 09:58:06AM +0100, David Howells wrote: > One thing I like about Willy's folio concept is that, as long as everyone uses > the proper accessor functions and macros, we can mostly ignore the fact that > they're 2^N sized/aligned and they're composed of exact multiples of pages. > What really matters are the correspondences between folio size/alignment and > medium/IO size/alignment, so you could look on the folio as being a tool to > disconnect the filesystem from the concept of pages. > > We could, in the future, in theory, allow the internal implementation of a > folio to shift from being a page array to being a kmalloc'd page list or > allow higher order units to be mixed in. The main thing we have to stop > people from doing is directly accessing the members of the struct. In the current state of the folio patches, I agree with you. But conceptually, folios are not disconnecting from the page beyond PAGE_SIZE -> PAGE_SIZE * (1 << folio_order()). This is why I asked what the intended endgame is. And I wonder if there is a bit of an alignment issue between FS and MM people about the exact nature and identity of this data structure. At the current stage of conversion, folio is a more clearly delineated API of what can be safely used from the FS for the interaction with the page cache and memory management. And it looks still flexible to make all sorts of changes, including how it's backed by memory. Compared with the page, where parts of the API are for the FS, but there are tons of members, functions, constants, and restrictions due to the page's role inside MM core code. Things you shouldn't be using, things you shouldn't be assuming from the fs side, but it's hard to tell which is which, because struct page is a lot of things. However, the MM narrative for folios is that they're an abstraction for regular vs compound pages. This is rather generic. Conceptually, it applies very broadly and deeply to MM core code: anonymous memory handling, reclaim, swapping, even the slab allocator uses them. If we follow through on this concept from the MM side - and that seems to be the plan - it's inevitable that the folio API will grow more MM-internal members, methods, as well as restrictions again in the process. Except for the tail page bits, I don't see too much in struct page that would not conceptually fit into this version of the folio. The cache_entry idea is really just to codify and retain that domain-specific minimalism and clarity from the filesystem side. As well as the flexibility around how backing memory is implemented, which I think could come in handy soon, but isn't the sole reason.