On Mon, Aug 14, 2017 at 01:14:57PM -0500, Christopher Lameter wrote: > 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. Nice wish list. Add pony. :) Any attempt to replace struct page with something more complex will have severe performance implications. I'll be glad proved otherwise. -- Kirill A. Shutemov -- 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>
