On Thu, Aug 10, 2017 at 02:28:49PM +1000, Dave Chinner wrote: > I've recently been looking into what is involved in sharing page > cache pages for shared extents in a filesystem. That is, create a > file, reflink it so there's two files but only one copy of the data > on disk, then read both files. Right now, we get two copies of the > data in the page cache - one in each inode mapping tree. Yep. We had a brief discussion of this at LSFMM (as you know, since you commented on the discussion): https://lwn.net/Articles/717950/ > If we scale this up to a container host which is using reflink trees > it's shared root images, there might be hundreds of copies of the > same data held in cache (i.e. one page per container). Given that > the filesystem knows that the underlying data extent is shared when > we go to read it, it's relatively easy to add mechanisms to the > filesystem to return the same page for all attempts to read the > from a shared extent from all inodes that share it. I agree the problem exists. Should we try to fix this problem, or should we steer people towards solutions which don't have this problem? The solutions I've been seeing use COW block devices instead of COW filesystems, and DAX to share the common pages between the host and each guest. > This leads me to think about crazy schemes like allocating a > "referring struct page" that is allocated for every reference to a > shared cache page and chain them all to the real struct page sorta > like we do for compound pages. That would give us a unique struct > page for each mapping tree and solve many of the issues, but I'm not > sure how viable such a concept would be. That's the solution I'd recommend looking into deeper. We've also talked about creating referring struct pages to support block size > page size. -- 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>
