On Fri, 11 Nov 2011 10:14:14 +0000 Mel Gorman <mgorman@xxxxxxx> wrote: > On Thu, Nov 10, 2011 at 03:37:32PM -0800, David Rientjes wrote: > > On Thu, 10 Nov 2011, Andrew Morton wrote: > > > > > > This patch once again prevents sync migration for transparent > > > > hugepage allocations as it is preferable to fail a THP allocation > > > > than stall. > > > > > > Who said? ;) Presumably some people would prefer to get lots of > > > huge pages for their 1000-hour compute job, and waiting a bit to get > > > those pages is acceptable. > > > > > > > Indeed. It seems like the behavior would better be controlled with > > /sys/kernel/mm/transparent_hugepage/defrag which is set aside specifically > > to control defragmentation for transparent hugepages and for that > > synchronous compaction should certainly apply. > > With khugepaged in place, it's adding a tunable that is unnecessary and > will not be used. Even if such a tuneable was created, the default > behaviour should be "do not stall". (who said?) Let me repeat my cruelly unanswered question: do we have sufficient instrumentation in place so that operators can determine that this change is causing them to get less huge pages than they'd like? Because some people really really want those huge pages. If we go and silently deprive them of those huge pages via changes like this, how do they *know* it's happening? And what are their options for making the kernel try harder to get those pages? And how do we communicate all of this to those operators? -- 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/ . Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/ Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>