AI实践哪家强?来 AICon, 解锁技术前沿,探寻产业新机! 了解详情
写点什么

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

  • 2023-08-14
    北京
  • 本文字数:6812 字

    阅读完需:约 22 分钟

解读 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 selectionSyntax 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 anoutright 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'sa 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 exampleof the way the code reads is different from how the code is executed,and that's potentially dangerous. Having a different type for tailand not-tail pages prevents the muddy thinking that can lead totail 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 本质没有改变。

作者介绍


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

2023-08-14 16:438082

评论

发布
暂无评论
发现更多内容

问界M9硬件升级的背后,藏着汽车的原子化之梦

脑极体

AI

1688代采系统功能深度解析(二):从技术角度揭秘“一键下单+批量采购”如何重塑采购效率

代码忍者

1688代采集运系统

MES管理系统:解决排产难题,提升企业竞争力

万界星空科技

生产管理系统 mes 制造业工厂 生产排班排产 智能排产

【签约】安兰携手第七在线 共启智能供应链新纪元

第七在线

aiXcoder上新Agent,内置MCP功能,端到端智能实现软件开发任务

新消费日报

融云「国家级通信产品」在沙特的交付实践

融云 RongCloud

Meta Llama 4大模型评价与分析

测试人

人工智能

Langchain快速入门: 一行代码实现流式输出

AI时代的一滴水

Python AI #LangChain LLM模型

英特尔和海信联合发布的会议垂域模型让商务会议更加安全智能

E科讯

AI智上 | 数智预算:业财数融 智算未来

用友智能财务

CST软件如何计算CMA中的模式加权系数MWC

思茂信息

cst操作 CST软件 CST Studio Suite

人工智能与增强现实购物体验:如何用AR与AI结合提升电商互动性?

天津汇柏科技有限公司

人工智能 增强现实 AI 人工智能

「DeepSeek-V3 技术解析」:DeepSeek-V3-Base 预训练阶段解析

Baihai IDP

人工智能 程序员 AI LLMs DeepSeek

征程 6 VIO通路断流分析

地平线开发者

自动驾驶; 算法工具链 地平线征程6

INFINI Console 系统集群状态异常修复方案

极限实验室

Kubernetes operator arm64

展开华为风帆,航向全球金融

脑极体

AI

deepseek如何制作ppt?DS高级使用技巧盘点!

职场工具箱

PPT 办公软件 AIGC AI生成PPT DeepSeek

GPT-4 即将退役,你准备好迎接 AI 的下一波冲击了吗?

测试人

人工智能

GitHub 上 Star 数排名前 40 的开发者工具

NocoBase

GitHub 开源 低代码 零代码 开发工具

征程 6 VIO通路断流分析

地平线开发者

自动驾驶; 算法工具链 地平线征程6

漫谈PID,聊聊实现与调参原理

芯动大师

KWDB MCP Server:解锁 LLM 与数据库的无缝协作

KaiwuDB

数据库

轻松拥有企业AI大脑,英特尔与MAXHUB共同发布AI PC

E科讯

2025 腾讯云城市峰会 •成都峰会 Al+办公协同创新专场 智启未来办公 驱动提效增长

人称T客

Nessus Professional 10.8.4 Auto Installer for macOS Sequoia

sysin

Nessus

《Operating System Concepts》阅读笔记:p748-p748

codists

操作系统

【HarmonyOS 5】makeObserved接口详解

GeorgeGcs

【HarmonyOS 5】VisionKit人脸活体检测详解

GeorgeGcs

又来一个挑战 Elastic 的,初识 SigLens

巴辉特

elasticsearch SigLens

等保二级与三级的深度剖析:差异究竟在哪?

黑龙江陆陆信息测评部

基于亚马逊云科技 Amazon Bedrock Tool Use 实现 Generative UI

亚马逊云科技 (Amazon Web Services)

解读 Linux 内存管理新特性 Memory folios_操作系统_徐宇_InfoQ精选文章