On Tue 17-01-17 21:49:45, Matthew Wilcox wrote: > 1. Exploiting multiorder radix tree entries. I believe we would do well > to attempt to allocate compound pages, insert them into the page cache, > and expect filesystems to be able to handle filling compound pages with > ->readpage. It will be more efficient because alloc_pages() can return > large entries out of the buddy list rather than breaking them down, > and it'll help reduce fragmentation. Kirill has patches to do this and I don't like the complexity it adds to pagecache handling code and each filesystem that would like to support this. I don't have objections to the general idea but the complexity of the current implementation just looks too big to me... > 2. Supporting filesystem block sizes > page size. Once we do the above > for efficiency, I think it then becomes trivial to support, eg 16k block > size filesystems on x86 machines with 4k pages. Heh, you wish... :) There's a big difference between opportunistically allocating a huge page and reliably have to provide high order page. Memory fragmentation issues will be difficult to deal with... Honza -- Jan Kara <jack@xxxxxxxx> SUSE Labs, CR -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@xxxxxxxxx. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>