On Fri, 29 Dec 2017, Dave Chinner wrote: > IOWs, just saying "it would be worthwhile to extend this to dentries > and inodes" completely misrepresents the sheer complexity of doing > so. We've known that atomic replacement is the big problem for > defragging inodes and dentries since this work was started, what, > more than 10 years? And while there's been many revisions of the > core defrag code since then, there has been no credible solution > presented for atomic replacement of objects with complex external > references. This is a show-stopper for inode/dentry slab defrag, and > I don't see that this new patchset is any different... Well this is a chance here to start an implementation since the radix tree is being reworked anyways. This is not dealing with dentries and inodes but it brings in the basic infrastructure into the slab allocators that can then be used to add other slab caches. Same warnings were given to me when we did page migration and it languished for 5 years. I have not had time to really focus on memory management issues since I left SGI about 9 years ago but it seems that I may now have the chance in 2018 to put a significant amount of time into making some progress. Large memory in servers has become a significant problem for my employer and the ability to allocate and manage contiguous memory blocks is essential to preserve performance and avoid constant reboot. So I will be looking for ways to address these issues. Maybe with a couple of approaches. -- 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>
