On Wed, 15 Jan 2014 04:07:20 +0800 Han Pingtian <hanpt@xxxxxxxxxxxxxxxxxx> wrote: > min_free_kbytes may be raised during THP's initialization. Sometimes, > this will change the value being set by user. Showing message will > clarify this confusion. > > Only show this message when changing the value set by user according to > Michal Hocko's suggestion. > > Showing the old value of min_free_kbytes according to Dave Hansen's > suggestion. This will give user the chance to restore old value of > min_free_kbytes. > This is all a bit nasty, isn't it? THP goes and alters min_free_kbytes to improve its own reliability, but min_free_kbytes is also user-modifiable. And over many years we have trained a *lot* of users to alter min_free_kbytes. Often to prevent nasty page allocation failure warnings from net drivers. So there are probably quite a lot of people out there who are manually rubbing out THP's efforts. And there may also be people who are setting min_free_kbytes to a value which is unnecessarily high for more recent kernels. I don't know what to do about this mess though :( > --- a/mm/huge_memory.c > +++ b/mm/huge_memory.c > @@ -130,8 +130,14 @@ static int set_recommended_min_free_kbytes(void) > (unsigned long) nr_free_buffer_pages() / 20); > recommended_min <<= (PAGE_SHIFT-10); > > - if (recommended_min > min_free_kbytes) > + if (recommended_min > min_free_kbytes) { > + if (user_min_free_kbytes >= 0) > + pr_info("raising min_free_kbytes from %d to %lu " > + "to help transparent hugepage allocations\n", > + min_free_kbytes, recommended_min); hm, recommended_min shouldn't have had long type. Oh well, we've done worse things. > min_free_kbytes = recommended_min; > + } > setup_per_zone_wmarks(); > return 0; > } -- 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>