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=-5.8 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,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 ED78AC4338F for ; Mon, 23 Aug 2021 22:06:34 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id D52F761076 for ; Mon, 23 Aug 2021 22:06:34 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S233013AbhHWWHQ (ORCPT ); Mon, 23 Aug 2021 18:07:16 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:51056 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229800AbhHWWHK (ORCPT ); Mon, 23 Aug 2021 18:07:10 -0400 Received: from mail-lf1-x136.google.com (mail-lf1-x136.google.com [IPv6:2a00:1450:4864:20::136]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 1ABD7C061757 for ; Mon, 23 Aug 2021 15:06:27 -0700 (PDT) Received: by mail-lf1-x136.google.com with SMTP id p38so41081351lfa.0 for ; Mon, 23 Aug 2021 15:06:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux-foundation.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=pNzxccHrLNvgtuARmJVk/6D6HUeCLBrBp9BAleU49Ss=; b=dwy8paMHkqyjLg1te3lCxkkLE6jDyUtbeifszfiKDvo9BBrM7XLb+10zYHDlIQZ6Gp s56jjZ/xv3KJAQ4Nz4+dvXUgTAQZmD21ubLfgu/r5vkDTVl0L1aNZ20sdEQO/9nYBeOg 2kehgthnitJpNSRy4IWcnjmoAiUzkkD/n4/q0= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=pNzxccHrLNvgtuARmJVk/6D6HUeCLBrBp9BAleU49Ss=; b=UNXSnwHdTLJE8k8C5Xae4uafsG+EtdWdDcFLS434AdO5pF+IReT8enrPzAzJcsd1C8 WYoAxEcfSJx943zFj794RakkGNCNxttXtEyOXVCmHDlo7OLXYf+ADNL4V30SV9OMyb7Q ktDTxFXFT3cKbJ+VUzyc8DxVaZLRTp9CNJoGfw7eVW08d4TjUGtBdcuYgb3Bd+FzdEkz l4B0uyINimS9yy8WiJy9xi3OnKJ9IfU+VSqsEJrlNPwq5KLXo9wGtjlrHLMBu7Z3uPXD CzpD5+LEjJ3HjYCfz7EN/4Xvi6swsYXW4/Q+zcVnzGjt2IC5fi4qmGKpWOYicmWPCpRx zyZg== X-Gm-Message-State: AOAM530/6UonasHjRDm7OfHfLPdDVrNOqX9fbF5jVFic3l5QBmLMwrxw 0c64tME4n95qxHl86lw9XU1BNVY8qu0siCuZ X-Google-Smtp-Source: ABdhPJzu9Uucu+9bGNpZTd9YuLb/QNnsrjlBCkLCdSeLR3BOysRDRpL5hQCGqrRJ9br/MFym7Bcppg== X-Received: by 2002:a05:6512:3905:: with SMTP id a5mr1369958lfu.354.1629756385156; Mon, 23 Aug 2021 15:06:25 -0700 (PDT) Received: from mail-lj1-f176.google.com (mail-lj1-f176.google.com. [209.85.208.176]) by smtp.gmail.com with ESMTPSA id l28sm539215lfj.202.2021.08.23.15.06.24 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 23 Aug 2021 15:06:25 -0700 (PDT) Received: by mail-lj1-f176.google.com with SMTP id q21so34036367ljj.6 for ; Mon, 23 Aug 2021 15:06:24 -0700 (PDT) X-Received: by 2002:a2e:7d0e:: with SMTP id y14mr29180236ljc.251.1629756384152; Mon, 23 Aug 2021 15:06:24 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Linus Torvalds Date: Mon, 23 Aug 2021 15:06:08 -0700 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [GIT PULL] Memory folios for v5.15 To: Johannes Weiner Cc: Matthew Wilcox , Linux-MM , linux-fsdevel , Linux Kernel Mailing List , Andrew Morton Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Aug 23, 2021 at 2:25 PM Johannes Weiner wrote: > > One one hand, the ambition appears to substitute folio for everything > that could be a base page or a compound page even inside core MM > code. Since there are very few places in the MM code that expressly > deal with tail pages in the first place, this amounts to a conversion > of most MM code - including the LRU management, reclaim, rmap, > migrate, swap, page fault code etc. - away from "the page". Yeah, honestly, I would have preferred to see this done the exact reverse way: make the rule be that "struct page" is always a head page, and anything that isn't a head page would be called something else. Because, as you say, head pages are the norm. And "folio" may be a clever term, but it's not very natural. Certainly not at all as intuitive or common as "page" as a name in the industry. That said, I see why Willy did it the way he did - it was easier to do it incrementally the way he did. But I do think it ends up with an end result that is kind of topsy turvy where the common "this is the core allocation" being called that odd "folio" thing, and then the simpler "page" name is for things that almost nobody should even care about. I'd have personally preferred to call the head page just a "page", and other pages "subpage" or something like that. I think that would be much more intuitive than "folio/page". Linus 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=-5.8 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,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 4CC16C4338F for ; Mon, 23 Aug 2021 22:06:29 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id B77FE61357 for ; Mon, 23 Aug 2021 22:06:28 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org B77FE61357 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=linux-foundation.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=kvack.org Received: by kanga.kvack.org (Postfix) id EF9698D0001; Mon, 23 Aug 2021 18:06:27 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id EA8296B0071; Mon, 23 Aug 2021 18:06:27 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id D96D38D0001; Mon, 23 Aug 2021 18:06:27 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0179.hostedemail.com [216.40.44.179]) by kanga.kvack.org (Postfix) with ESMTP id BD0056B006C for ; Mon, 23 Aug 2021 18:06:27 -0400 (EDT) Received: from smtpin31.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay01.hostedemail.com (Postfix) with ESMTP id 3CECC18150C22 for ; Mon, 23 Aug 2021 22:06:27 +0000 (UTC) X-FDA: 78507730014.31.F768C16 Received: from mail-lj1-f177.google.com (mail-lj1-f177.google.com [209.85.208.177]) by imf01.hostedemail.com (Postfix) with ESMTP id DA9D75023256 for ; Mon, 23 Aug 2021 22:06:26 +0000 (UTC) Received: by mail-lj1-f177.google.com with SMTP id y6so34091995lje.2 for ; Mon, 23 Aug 2021 15:06:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux-foundation.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=pNzxccHrLNvgtuARmJVk/6D6HUeCLBrBp9BAleU49Ss=; b=dwy8paMHkqyjLg1te3lCxkkLE6jDyUtbeifszfiKDvo9BBrM7XLb+10zYHDlIQZ6Gp s56jjZ/xv3KJAQ4Nz4+dvXUgTAQZmD21ubLfgu/r5vkDTVl0L1aNZ20sdEQO/9nYBeOg 2kehgthnitJpNSRy4IWcnjmoAiUzkkD/n4/q0= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=pNzxccHrLNvgtuARmJVk/6D6HUeCLBrBp9BAleU49Ss=; b=GI4A4llaO1rPIAwY00rG9rIJzxw3arv6/HeAu6YQWDNUrcNZKQlQIahSYDVwVYwEgk LdXsjAV9xzgwQwA65BFYzPvUXYThhQrxykfYKN9tzfNEz6VmmGfg0wSZvENFmWZOXed4 EEjeeEhBEEq1tDvycNF+Qudz4t7XzAaivjZ6nYcegbtBGFhQGLH7VQD93mSu/PjEK6S/ ZhJhkpDsL+dM1aPe14sARGK0CDC3jgu8+DSBX3jyUz344WhsJKNEtJDALJ0mHPfYsEPP z4HvbH/jbxQbTKk+wLFqn4A6/mrTgVUNA6AEI5h6slT9guVUTLmKkIeIM5B5NPIOp/Il 5GjA== X-Gm-Message-State: AOAM531MfbXTJ2bhupj+tLwuUFPjR0P9SkdL/YWdnHpLzYPvOKOOjfi0 JmJKv63Uz8QQ4LYLJye6Ax8f9tJMXmC7ySDc X-Google-Smtp-Source: ABdhPJwDYtSDkt0iBGXIW8C/rmPREjJwvGFj/d2E2sQcvr29qHX+iUdqXoZTYLHxX+2H03LGpPV0Gg== X-Received: by 2002:a2e:86d6:: with SMTP id n22mr11832986ljj.416.1629756385005; Mon, 23 Aug 2021 15:06:25 -0700 (PDT) Received: from mail-lj1-f176.google.com (mail-lj1-f176.google.com. [209.85.208.176]) by smtp.gmail.com with ESMTPSA id c8sm1559028lfv.159.2021.08.23.15.06.24 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 23 Aug 2021 15:06:24 -0700 (PDT) Received: by mail-lj1-f176.google.com with SMTP id c12so34103962ljr.5 for ; Mon, 23 Aug 2021 15:06:24 -0700 (PDT) X-Received: by 2002:a2e:7d0e:: with SMTP id y14mr29180236ljc.251.1629756384152; Mon, 23 Aug 2021 15:06:24 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Linus Torvalds Date: Mon, 23 Aug 2021 15:06:08 -0700 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [GIT PULL] Memory folios for v5.15 To: Johannes Weiner Cc: Matthew Wilcox , Linux-MM , linux-fsdevel , Linux Kernel Mailing List , Andrew Morton Content-Type: text/plain; charset="UTF-8" Authentication-Results: imf01.hostedemail.com; dkim=pass header.d=linux-foundation.org header.s=google header.b=dwy8paMH; spf=pass (imf01.hostedemail.com: domain of torvalds@linuxfoundation.org designates 209.85.208.177 as permitted sender) smtp.mailfrom=torvalds@linuxfoundation.org; dmarc=none X-Stat-Signature: c9tcf6thmy36xybrsrf76ufx8bom79om X-Rspamd-Queue-Id: DA9D75023256 X-Rspamd-Server: rspam04 X-HE-Tag: 1629756386-531459 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 Mon, Aug 23, 2021 at 2:25 PM Johannes Weiner wrote: > > One one hand, the ambition appears to substitute folio for everything > that could be a base page or a compound page even inside core MM > code. Since there are very few places in the MM code that expressly > deal with tail pages in the first place, this amounts to a conversion > of most MM code - including the LRU management, reclaim, rmap, > migrate, swap, page fault code etc. - away from "the page". Yeah, honestly, I would have preferred to see this done the exact reverse way: make the rule be that "struct page" is always a head page, and anything that isn't a head page would be called something else. Because, as you say, head pages are the norm. And "folio" may be a clever term, but it's not very natural. Certainly not at all as intuitive or common as "page" as a name in the industry. That said, I see why Willy did it the way he did - it was easier to do it incrementally the way he did. But I do think it ends up with an end result that is kind of topsy turvy where the common "this is the core allocation" being called that odd "folio" thing, and then the simpler "page" name is for things that almost nobody should even care about. I'd have personally preferred to call the head page just a "page", and other pages "subpage" or something like that. I think that would be much more intuitive than "folio/page". Linus