On Mon 05-06-17 11:15:41, Liam R. Howlett wrote: > * Michal Hocko <mhocko@xxxxxxxx> [170605 00:57]: > > On Fri 02-06-17 20:54:13, Liam R. Howlett wrote: > > > When the user specifies too many hugepages or an invalid > > > default_hugepagesz the communication to the user is implicit in the > > > allocation message. This patch adds a warning when the desired page > > > count is not allocated and prints an error when the default_hugepagesz > > > is invalid on boot. > > > > We do not warn when doing echo $NUM > nr_hugepages, so why should we > > behave any different during the boot? > > During boot hugepages will allocate until there is a fraction of the > hugepage size left. That is, we allocate until either the request is > satisfied or memory for the pages is exhausted. When memory for the > pages is exhausted, it will most likely lead to the system failing with > the OOM manager not finding enough (or anything) to kill (unless you're > using really big hugepages in the order of 100s of MB or in the GBs). > The user will most likely see the OOM messages much later in the boot > sequence than the implicitly stated message. Worse yet, you may even > get an OOM for each processor which causes many pages of OOMs on modern > systems. Although these messages will be printed earlier than the OOM > messages, at least giving the user errors and warnings will highlight > the configuration as an issue. I'm trying to point the user in the > right direction by providing a more robust statement of what is failing. Well, an oom report will tell us how much memory is eaten by hugetlb so you would get a clue that something is misconfigured. -- Michal Hocko SUSE Labs -- 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>
