* Mel Gorman <mgorman@xxxxxxxxxxxxxxxxxxx> [2016-08-04 11:28:01]: > > > > > > Oh, and the dentry/inode caches are sized based on 100% of memory, not > > > the 5% that's left after the fadump reservation? > > > > Yes, the dentry/inode caches are sized based on the 100% memory. > > > > By and large, I'm not a major fan of introducing an API to disable it for > a single feature that is arch-specific because it's very heavy handed. > There is no guarantee that the existence of fadump will cause a failure okay. > > If fadump is reserving memory and alloc_large_system_hash(HASH_EARLY) > does not know about then then would an arch-specific callback for > arch_reserved_kernel_pages() be more appropriate? fadump would need to > return how many pages it reserved there. That would shrink the size of > the inode and dentry hash tables when booting with 95% of memory > reserved. > > That approach would limit the impact to ppc64 and would be less costly than > doing a memblock walk instead of using nr_kernel_pages for everyone else. > I have posted a patch based on Mel and Dave's feedback http://lkml.kernel.org/r/1470318165-2521-1-git-send-email-srikar@xxxxxxxxxxxxxxxxxx -- Thanks and Regards Srikar Dronamraju -- 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>