On 06/14/2017 12:27 AM, Michal Hocko wrote: > On Tue 13-06-17 09:26:15, Mike Kravetz wrote: >> A thought somewhat related to this discussion: >> >> I noticed that huge pages specified on the kernel command line are allocated >> via 'subsys_initcall'. This is before 'fs_initcall', even though these huge >> pages are only used by hugetlbfs. Was just thinking that it might be better >> to move huge page allocations to later in the init process. At least make >> them part of fs_initcall if not late_initcall? >> >> Only reason for doing this is because huge page allocations are fairly >> tolerant of allocation failure. > > I am not really familiar with the initcall hierarchy to be honest. I > even do not understand what relattion does fs_initcall have to > allocation failures. Could you be more specific? The short answer is never mind. We can not easily change where huge pages are allocated as pointed out here: https://patchwork.kernel.org/patch/7837381/ The longer explanation of my thoughts on moving location of allocations: Liam was saying that someone was getting OOMs because they allocated too many huge pages. It also seems that this happened during boot. I may be reading too much into his comments. My thought is that this 'may' not happen if huge pages were allocated later in the boot process. If they were allocated after boot, this would not even be an issue. So, I started looking at where they were allocated in the initcall hierarchy. huge pages are allocated via subsys_initcall which (IIUC) happens before fs_initcall. It seems to me that perhaps huge page allocation belongs in fs_initcall as the pre-allocated pages are only used by hugetlbfs. Moving huge page allocation from subsys_initcall to fs_initcall is unlikely to have any impact on the OOMs that Liam was trying to flag. In fact it may not have an impact on any such issues. But, in a way it does seem 'more correct'. Nobody in the init process should be depending on huge page allocation (I think), so what if we moved it all the way to the end of initcall processing: late_initcall. Then perhaps it might have an impact on such issues. -- Mike Kravetz -- 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>
