On Wed, Sep 2, 2015 at 1:26 AM, David Rientjes <rientjes@xxxxxxxxxx> wrote: > On Tue, 25 Aug 2015, Vlastimil Babka wrote: > >> > THP works very well when system has a lot of free memory. >> > Probably default should be weakened to "only if we have tons of free >> > memory". >> > For example allocate THP pages atomically, only if buddy allocator already >> > has huge pages. Also them could be pre-zeroed in background. >> >> I've been proposing series that try to move more THP allocation activity from >> the page faults into khugepaged, but no success yet. >> >> Maybe we should just start with changing the default of >> /sys/kernel/mm/transparent_hugepage/defrag to "madvise". > > I would need to revert this internally to avoid performance degradation, I > believe others would report the same. What about adding new mode "guess" -- something between always and madvise? In this mode kernel tries to avoid performance impact for non-madvised vmas and allocates 0-order pages if hugepages are not available right now. (for example do allocations with GFP_NOWAIT) I think we'll get all benefits without losing performance. > >> This would remove the >> reclaim and compaction for page faults and quickly fallback to order-0 pages. >> The compaction is already crippled enough there with the GFP_TRANSHUGE >> specific decisions in __alloc_pages_slowpath(). I've noticed it failing >> miserably in the transhuge-stress recently, so it seems it's not worth to try >> at all. With changing the default we can kill those GFP_TRANSHUGE checks and >> assume that whoever uses the madvise does actually want to try harder. >> > > I think the work that is being done on moving compaction to khugepaged as > well as periodic synchronous compaction of all memory is the way to go to > avoid lengthy stalls during fault. > >> Of course that does nothing about zeroing. I don't know how huge issue is that >> one? >> > > I don't believe it is an issue that cannot be worked around in userspace > either with MADV_NOHUGEPAGE or PR_SET_THP_DISABLE. -- 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>