LWN: Comments on "Various page cache issues"

Various page cache issues

kevinm — Thu, 03 Apr 2014 02:20:02 +0000

On 64 bit systems, could you solve the higher-order allocation problem by using a virtually-remapped page cache?

Changing the logical page size

dgc — Sun, 30 Mar 2014 22:09:14 +0000

We did actually touch on using larger base page sizes, but that really isn't a complete solution to any of the problems. e.g. only go to a 16k page size and we still need to change code somewhere to support 64k filesystem block sizes. It also has other impacts across the rest of the kernel, such as kernel thread stacks become much larger, and we can waste much more memory in the page cache when caching lots of small files. IOWs, it is one possible solution, but it's not a magic bullet.

-Dave.

Changing the logical page size

arnd — Thu, 27 Mar 2014 11:38:08 +0000

Wouldn't we be able to provide relief for all three issues by supporting larger (virtual) pages at compile time? Of course there is a significant cost in memory consumption by increasing the page size to e.g. 16KB or 64KB, but some architectures (powerpc64, arm64) support that already, and you can always have a PAGE_SIZE that is a multiple of the hardware page size by using multiple PTEs for each 'struct page'. On ARM32, I believe we could support up to 32KB logical pages without significant user space impact, beyond that there is a problem with ELF section alignment. Not sure if there are limitations on x86 that prevent this.