On Wed, Nov 12, 2014 at 11:17:16AM +0900, Joonsoo Kim wrote:
On Wed, Nov 12, 2014 at 03:22:41AM +0200, Kirill A. Shutemov wrote:
On Tue, Nov 11, 2014 at 04:49:13PM -0800, Andrew Morton wrote:
On Tue, 11 Nov 2014 18:36:28 -0600 (CST) Christoph Lameter cl@linux.com wrote:
On Tue, 11 Nov 2014, Andrew Morton wrote:
There's no point in doing
#define GFP_SLAB_BUG_MASK (__GFP_DMA32|__GFP_HIGHMEM|~__GFP_BITS_MASK)
because __GFP_DMA32|__GFP_HIGHMEM are already part of ~__GFP_BITS_MASK.
?? ~__GFP_BITS_MASK means bits 25 to 31 are set.
__GFP_DMA32 is bit 2 and __GFP_HIGHMEM is bit 1.
Ah, yes, OK.
I suppose it's possible that __GFP_HIGHMEM was set.
do_huge_pmd_anonymous_page ->pte_alloc_one ->alloc_pages(__userpte_alloc_gfp==__GFP_HIGHMEM)
do_huge_pmd_anonymous_page alloc_hugepage_vma alloc_pages_vma(GFP_TRANSHUGE)
GFP_TRANSHUGE contains GFP_HIGHUSER_MOVABLE, which has __GFP_HIGHMEM.
Hello, Kirill.
BTW, why does GFP_TRANSHUGE have MOVABLE flag despite it isn't movable? After breaking hugepage, it could be movable, but, it may prevent CMA from working correctly until break.
Again, the same alloc vs. free gfp_mask: we want page allocator to move pages around to find space from THP, but resulting page is no really movable.
I've tried to look into making THP movable: it requires quite a bit of infrastructure changes around rmap: try_to_unmap*(), remove_migration_pmd(), migration entries for PMDs, etc. I gets ugly pretty fast :-/ I probably need to give it second try. No promises.