Hi Matthew, (Sorry for the late response, I could not find time earlier) On Thu, Jul 15, 2021 at 04:34:46AM +0100, Matthew Wilcox (Oracle) wrote: > Managing memory in 4KiB pages is a serious overhead. Many benchmarks > benefit from a larger "page size". As an example, an earlier iteration > of this idea which used compound pages (and wasn't particularly tuned) > got a 7% performance boost when compiling the kernel. > > Using compound pages or THPs exposes a weakness of our type system. > Functions are often unprepared for compound pages to be passed to them, > and may only act on PAGE_SIZE chunks. Even functions which are aware of > compound pages may expect a head page, and do the wrong thing if passed > a tail page. > > We also waste a lot of instructions ensuring that we're not looking at > a tail page. Almost every call to PageFoo() contains one or more hidden > calls to compound_head(). This also happens for get_page(), put_page() > and many more functions. > > This patch series uses a new type, the struct folio, to manage memory. > It converts enough of the page cache, iomap and XFS to use folios instead > of pages, and then adds support for multi-page folios. It passes xfstests > (running on XFS) with no regressions compared to v5.14-rc1. I like the idea of folio and that first patches I've reviewed look good. Most of the changelogs (at least at the first patches) mention reduction of the kernel size for your configuration on x86. I wonder, what happens if you build the kernel with "non-distro" configuration, e.g. defconfig or tiny.config? Also, what is the difference on !x86 builds? > Git: https://git.infradead.org/users/willy/pagecache.git/shortlog/refs/tags/folio_14 -- Sincerely yours, Mike.
