On Mon, 14 Aug 2017, Dave Chinner wrote: > > Use XFS+reflink+DAX on top of this loop device. Now there's only one > > copy of each page in RAM. > > Yes, I can see how that could work. Crazy, out of the box, abuses > DAX for non-DAX purposes and uses stuff we haven't enabled yet > because nobody has done the work to validate it. Full points for > creativity! :) Another not so crazy solution is to break the 1-1 relation between page structs and pages. We already have issues with huge pages where one struct page may represent 2m of memmory using 512 or so page struct. Therer are also constantly attempts to expand struct page. So how about an m->n relationship? Any page (may it be 4k, 2m or 1G) has one page struct for each mapping that it is a member of? Maybe a the page state could consist of a base struct that describes the page state and then 1..n pieces of mapping information? In the future other state info could be added to the end if we allow dynamic sizing of page structs. This would also allow the inevitable creeping page struct bloat to get completely out of control. -- 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>
