On 06/16/2017 12:07 PM, Andrew Morton wrote: > On Mon, 12 Jun 2017 21:35:17 -0400 "Liam R. Howlett" <Liam.Howlett@xxxxxxxxxx> wrote: > >>> >>>> If there's no message stating any >>>> configuration issue, then many admins would probably think something is >>>> seriously broken and it's not just a simple typo of K vs M. >>>> >>>> Even though this doesn't catch all errors, I think it's a worth while >>>> change since this is currently a silent failure which results in a >>>> system crash. >>> >>> Seriously, this warning just doesn't help in _most_ miscofigurations. It >>> just focuses on one particular which really requires to misconfigure >>> really badly. And there are way too many other ways to screw your system >>> that way, yet we do not warn about many of those. So just try to step >>> back and think whether this is something we actually do care about and >>> if yes then try to come up with a more reasonable warning which would >>> cover a wider range of misconfigurations. >> >> Understood. Again, I appreciate all the time you have taken on my >> patch and explaining your points. I will look at this again as you >> have suggested. > > So do we want to drop > mm-hugetlb-warn-the-user-when-issues-arise-on-boot-due-to-hugepages.patch? > > I'd be inclined to keep it if Liam found it a bit useful - it does have > some overhead, but half the patch is in __init code... > Before sending out this patch, I asked Liam off list why he was doing it. Was it something he just thought would be useful? Or, was there some type of user situation/need. He said that he had been called in to assist on several occasions when a system OOMed during boot. In almost all of these situations, the user had grossly misconfigured huge pages. DB users want to pre-allocate just the right amount of huge pages, but sometimes they can be really off. In such situations, the huge page init code just allocates as many huge pages as it can and reports the number allocated. There is no indication that it quit allocating because it ran out of memory. Of course, a user could compare the number in the message to what they requested on the command line to determine if they got all the huge pages they requested. The thought was that it would be useful to at least flag this situation. That way, the user might be able to better relate the huge page allocation failure to the OOM. I'm not sure if the e-mail discussion made it obvious that this is something he has seen on several occasions. I see Michal's point that this will only flag the situation where someone configures huge pages very badly. And, a more extensive look at the situation of misconfiguring huge pages might be in order. But, this has happened on several occasions which led to the creation of this patch. -- 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>
