解读 Linux 内存管理新特性 Memory folios

本文内容基于 Linux 5.16，folio 基础部分开始合入。截止到 Linux 6.5，folio 已经有很大进展，会在后续文章中介绍。

folio 技术特性

引用 LWN:：Memory folios ：https://lwn.net/Articles/856016/ 和 Merge tag 'folio-5.16'：https://github.com/torvalds/linux/commit/49f8275c7d92。

如何理解 folio？

Add memory folios, a new type to represent either order-0 pages or the head page of a compound page.folio 可以看成是 page 的一层包装，没有开销的那种。folio 可以是单个页，也可以是复合页。

（图片引用围绕 HugeTLB 的极致优化）

上图是 page 结构体的示意图，64 字节管理 flags, lru, mapping, index, private, {ref_, map_}count, memcg_data 等信息。当 page 是复合页的时候，上述 flags 等信息在 head page 中，tail page 则复用管理 compound_{head, mapcount, order, nr, dtor} 等信息。

struct folio {
        /* private: don't document the anon union */
        union {
                struct {
        /* public: */
                        unsigned long flags;
                        struct list_head lru;
                        struct address_space *mapping;
                        pgoff_t index;
                        void *private;
                        atomic_t _mapcount;
                        atomic_t _refcount;
#ifdef CONFIG_MEMCG
                        unsigned long memcg_data;
#endif
        /* private: the union with struct page is transitional */
                };
                struct page page;
        };
};

folio 的结构定义中，flags, lru 等信息和 page 完全一致，因此可以和 page 进行 union。这样可以直接使用 folio->flags  而不用 folio->page->flags。

#define page_folio(p)           (_Generic((p),                          \
        const struct page *:    (const struct folio *)_compound_head(p), \
        struct page *:          (struct folio *)_compound_head(p)))

#define nth_page(page,n) ((page) + (n))
#define folio_page(folio, n)    nth_page(&(folio)->page, n)

第一眼看 page_folio 可能有点懵，其实等效于：

switch (typeof(p)) {
  case const struct page *:
    return (const struct folio *)_compound_head(p);
  case struct page *:
    return (struct folio *)_compound_head(p)));
}

就这么简单。

_Generic 是 C11 STANDARD - 6.5.1.1 Generic selection（https://www.open-std.org/JTC1/sc22/wg14/www/docs/n1570.pdf） 特性，语法如下：

Generic selection
Syntax
 generic-selection:
  _Generic ( assignment-expression , generic-assoc-list )
 generic-assoc-list:
  generic-association
  generic-assoc-list , generic-association
 generic-association:
  type-name : assignment-expression
  default : assignment-expression

page 和 folio 的相互转换也很直接。不管 head，tail page，转化为 folio 时，意义等同于获取 head page 对应的 folio；folio 转化为 page 时，folio->page 用于获取 head page，folio_page(folio, n) 可以用于获取 tail page。

问题是，本来 page 就能代表 base page，或者 compound page，为什么还需要引入 folio？

folio 能做什么？

The folio type allows a function to declare that it's expecting only a head page. Almost incidentally, this allows us to remove various calls to VM_BUG_ON(PageTail(page)) and compound_head().page 的含义太多了，可以是 base page，可以是 compound head page，还可以是 compound tail page。

如上述所说，page 元信息都存放在 head page（base page 可以看成是 head page）上，例如 page->mapping, page->index 等。但在 mm 路径上，传递进来的 page 参数总是需要判断是 head page 还是 tail page。由于没有上下文缓存，mm 路径上可能会存在太多重复的 compound_head 调用。

这里以 mem_cgroup_move_account 函数调用举例，一次 mem_cgroup_move_account 调用，最多能执行 7 次 compound_head。

static inline struct page *compound_head(struct page *page)
{
        unsigned long head = READ_ONCE(page->compound_head);

        if (unlikely(head & 1))
                return (struct page *) (head - 1);
        return page;
}

再以 page_mapping(page) 为例具体分析，进入函数内部，首先执行 compound_head(page) 获取 page mapping 等信息。另外还有一个分支 PageSwapCache(page) ，当执行这个分支函数的时候，传递的是 page，函数内部还需执行一次 compound_head(page) 来获取 page flag 信息。

struct address_space *page_mapping(struct page *page)
{
        struct address_space *mapping;

        page = compound_head(page);

        /* This happens if someone calls flush_dcache_page on slab page */
        if (unlikely(PageSlab(page)))
                return NULL;

        if (unlikely(PageSwapCache(page))) {
                swp_entry_t entry;

                entry.val = page_private(page);
                return swap_address_space(entry);
        }

        mapping = page->mapping;
        if ((unsigned long)mapping & PAGE_MAPPING_ANON)
                return NULL;

        return (void *)((unsigned long)mapping & ~PAGE_MAPPING_FLAGS);
}
EXPORT_SYMBOL(page_mapping);

当切换到 folio 之后，page_mapping(page) 对应 folio_mapping(folio) ，而 folio 隐含着 folio 本身就是 head page，因此两个 compound_head(page) 的调用就省略了。

mem_cgroup_move_account 仅仅是冰山一角，mm 路径上到处是 compound_head 的调用。积少成多，不仅执行开销减少了，开发者也能得到提示，当前 folio 一定是 head page，减少判断分支。

folio 的直接价值

1）减少太多冗余 compound_head 的调用。

2）给开发者提示，看到 folio，就能认定这是 head page。

3）修复潜在的 tail page 导致的 bug。

Here's an example where our current confusion between "any page"
and "head page" at least produces confusing behaviour, if not an
outright bug, isolate_migratepages_block():

        page = pfn_to_page(low_pfn);
        if (PageCompound(page) && !cc->alloc_contig) {
                const unsigned int order = compound_order(page);

                if (likely(order < MAX_ORDER))
                        low_pfn += (1UL << order) - 1;
                goto isolate_fail;
        }

compound_order() does not expect a tail page; it returns 0 unless it's
a head page.  I think what we actually want to do here is:

        if (!cc->alloc_contig) {
            struct page *head = compound_head(page);
            if (PageHead(head)) {
                const unsigned int order = compound_order(head);

                low_pfn |= (1UL << order) - 1;
                goto isolate_fail;
            }
        }

Not earth-shattering; not even necessarily a bug.  But it's an example
of the way the code reads is different from how the code is executed,
and that's potentially dangerous.  Having a different type for tail
and not-tail pages prevents the muddy thinking that can lead to
tail pages being passed to compound_order().

folio-5.16 已经合入

This converts just parts of the core MM and the page cache.willy/pagecache.git 共有 209 commit。这次 5.16 的合并窗口中，作者 Matthew Wilcox (Oracle) willy@infradead.org 先合入 folio 基础部分，即 Merge tag folio-5.16，其中包含 90 commits，74 changed files with 2914 additions and 1703 deletions。除了 folio 定义等基础设施之外，这次改动主要集中在 memcg, filemap, writeback 部分。

folio-5.16 用 folio 逐步取代 page 的过程，似乎值得一提。mm 路径太多了，如果强迫症一次性替换完，就得 top-down 的方式，从 page 分配的地方改成 folio，然后一路改下去。这不现实，几乎要修改整个 mm 文件夹了。

folio-5.16 采用的是 bottom-up 的方式，在 mm 路径的某个函数开始，将 page 替换成 folio，其内部所有实现都用 folio，形成一个“闭包”。然后修改其 caller function，用 folio 作为参数调用该函数。直到所有 caller function 都改完了，那么这个“闭包”又扩展了一层。有些函数的调用者很多，一时改不完，folio-5.16 就提供了一层 wrapper。这里以 page_mapping/folio_mapping 为例。

首先闭包里是 folio_test_slab(folio)，folio_test_swapcache(folio) 等基础设施，然后向上扩展到 folio_mapping。page_mapping 的调用者很多，mem_cgroup_move_account 能顺利地调用 folio_mapping，而 page_evictable 却还是保留使用 page_mapping。那么闭包在这里停止扩展。

struct address_space *folio_mapping(struct folio *folio)
{
        struct address_space *mapping;

        /* This happens if someone calls flush_dcache_page on slab page */
        if (unlikely(folio_test_slab(folio)))
                return NULL;

        if (unlikely(folio_test_swapcache(folio)))
                return swap_address_space(folio_swap_entry(folio));

        mapping = folio->mapping;
        if ((unsigned long)mapping & PAGE_MAPPING_ANON)
                return NULL;

        return (void *)((unsigned long)mapping & ~PAGE_MAPPING_FLAGS);
}
struct address_space *page_mapping(struct page *page)
{
        return folio_mapping(page_folio(page));
}

mem_cgroup_move_account(page, ...) {
  folio = page_folio(page);
  mapping = folio_mapping(folio);
}

page_evictable(page, ...) {
  ret = !mapping_unevictable(page_mapping(page)) && !PageMlocked(page);
}

关于 folio，还需要了解什么？

很多小伙伴看到这里是不是和我有一样的感受：就这些吗？仅仅是 compound_head 的问题吗？

我不得不去学习 LWN: A discussion on folios（https://lwn.net/Articles/869942/），LPC 2021 - File Systems MC（https://www.youtube.com/watch?v=U6HYrd85hQ8&t=1475s） 大佬关于 folio 的讨论。然后发现 Matthew Wilcox 的主题不是《The folio》，而是《Efficient buffered I/O》。事情并不简单。

这次 folio-5.16 合入的都是 fs 相关的代码，组里大佬提到 “Linux-mm 社区大佬不同意全部把 page 替换成 folio，对于匿名页和 slab，短期内还是不能替换”。于是我继续翻阅 Linux-mm 邮件列表。

关于 folio 的社区讨论

命名

首先是 Linus，Linus 表示他不讨厌这组 patch，因为这组 patch 确实解决了 compound_head 的问题；但是他也不喜欢这组 patch，原因是 folio 听起来不直观。

经过若干关于取名的讨论，当然命名最后还是 folio。

FS 开发者的意见

目前 page cache 中都是 4K page，page cache 中的大页也是只读的，例如代码大页（https://openanolis.cn/sig/Cloud-Kernel/doc/475049355931222178）特性。为什么 Transparent huge pages in the page cache 一直没有实现，可以参考这篇 LWN（https://lwn.net/Articles/686690/）。其中一个原因是，要实现 读写 file THP，基于 buffer_head 的 fs 对 page cache 的处理过于复杂。

• buffer_head：buffer_head 代表的是物理内存映射的块设备偏移位置，一般一个 buffer_head 也是 4K 大小，这样一个 buffer_head 正好对应一个 page。某些文件系统可能采用更小的 block size，例如 1K，或者 512 字节。这样一个 page 最多可以有 4 或者 8 个 buffer_head 结构体来描述其内存对应的物理磁盘位置。这样，在处理 multi-page 读写的时候，每个 page 都需要通过 get_block 获取 page 和 磁盘偏移的关系，低效且复杂。
• iomap：iomap 最初是从 XFS 内部拿出来的，基于 extent，天然支持 multi-page。即在处理 multi-page 读写的时候，仅需一次翻译就能获取所有 page 和 磁盘偏移的关系。通过 iomap，文件系统与 page cache 隔离开来了，例如，它们在表示大小的时候都使用字节，而不是有多少 page。因此，Matthew Wilcox 建议任何直接使用 page cache 的文件系统都应该考虑要换到 iomap 或 netfs_lib 了。隔离 fs 与 page cache 的方式或许不止 folio，但是例如 scatter gather 是不被接受的，抽象太复杂。这也是为什么 folio 先在 XFS/AFS 中落地了，因为这两个文件系统就是基于 iomap 的。这也是为什么 FS 开发者都强烈希望 folio 被合入，他们可以方便地在 page cache 中使用更大的 page，这个做法可以使文件系统的 I/O 更有效率。

buffer_head 有一些功能是当前 iomap 仍然缺乏的。而 folio 的合入，能让 iomap 得到推进，从而使 block-based 文件系统能够改成使用 iomap。

MM 开发者的意见

最大的异议来自 Johannes Weiner，他承认 compound_head 的问题，但觉得修复该问题而引入这么大的改动不值得；同时认为 folio 对 fs 的所做的优化，anonymous page 不需要。

Unlike the filesystem side, this seems like a lot of churn for very little tangible value. And leaves us with an end result that nobody appears to be terribly excited about.But the folio abstraction is too low-level to use JUST for file cache and NOT for anon. It's too close to the page layer itself and would duplicate too much of it to be maintainable side by side.最后在  Kirill A. Shutemov、Michal Hocko 等大佬的力挺 folio 态度下，Johannes Weiner 也妥协了。

社区讨论到最后，针对 folio 的反对意见在 folio-5.15 的代码中都已经不存在了，但错过了 5.15 的合并窗口，因此这次 folio-5.16 原封不动被合入了。

folio 的深层价值

I think the problem with folio is that everybody wants to read in her/his hopes and dreams into it and gets disappointed when see their somewhat related problem doesn't get magically fixed with folio. Folio started as a way to relief pain from dealing with compound pages. It provides an unified view on base pages and compound pages. That's it. It is required ground work for wider adoption of compound pages in page cache. But it also will be useful for anon THP and hugetlb. Based on adoption rate and resulting code, the new abstraction has nice downstream effects. It may be suitable for more than it was intended for initially. That's great. But if it doesn't solve your problem... well, sorry... The patchset makes a nice step forward and cuts back on mess I created on the way to huge-tmpfs. I would be glad to see the patchset upstream. -- Kirill A. Shutemov

大家都知道“struct page 相关的混乱”，但没有人去解决，大家都在默默忍受这长期以来的困扰，在代码中充斥着如下代码。

if (compound_head(page)) // do A;
else                     // do B;

folio 并不完美，或许因为大家期望太高，导致少数人对 folio 的最终实现表示失望。但多数人认为 folio 是在正确方向上的重要一步。毕竟后续还有更多工作要实现。

写在最后

folio 后续的开发计划如下：

对于 5.17，我们打算转换各种文件系统(XFS 和 AFS 已经准备好了；其他文件系统可能会做到)，也可以将更多的 MM 和页面缓存转换为对开页。对于 5.18，应该准备好多页的开本。

此外，folio 还能提升性能：

80%的优势是真实的，但似乎是一个人为的基准(postgres 启动，这不是一个严重的工作量)。实际工作负载(例如构建内核，在稳定状态下运行 postgres 等)似乎在 0-10%之间受益。folio-5.16 减少大量 compound_head 调用，在 sys 高的 micro benchmark 中应当有性能提升。未实测。

folio-5.18 multi-page folios 支持之后，理论上 I/O 效率能提升，拭目以待。

开发者要想使用 folio，FS 开发者最应该做的就是把那些仍然使用 buffer head 的文件系统转换为使用 iomap 进行 I/O，至少对于那些 block-based 文件系统都应该这么做。其他开发者欣然接受 folio 即可，基于 5.16+ 开发的新特性能用 folio 就用 folio，熟悉一下 API 即可，内存分配回收等 API 本质没有改变。

作者介绍

徐宇，阿里云研发工程师。