On Tue, Nov 11, 2014 at 05:44:12PM -0800, Andrew Morton wrote:
On Wed, 12 Nov 2014 10:22:45 +0900 Joonsoo Kim iamjoonsoo.kim@lge.com wrote:
On Tue, Nov 11, 2014 at 05:02:43PM -0800, Andrew Morton wrote:
On Wed, 12 Nov 2014 00:54:01 +0000 Luke Dashjr luke@dashjr.org wrote:
On Wednesday, November 12, 2014 12:49:13 AM Andrew Morton wrote:
But anyway - Luke, please attach your .config to https://bugzilla.kernel.org/show_bug.cgi?id=87891?
OK, thanks. No CONFIG_HIGHMEM of course. I'm stumped.
Hello, Andrew.
I think that the cause is GFP_HIGHMEM. GFP_HIGHMEM is always defined regardless CONFIG_HIGHMEM. Please look at the do_huge_pmd_anonymous_page(). It calls alloc_hugepage_vma() and then alloc_pages_vma() is called with alloc_hugepage_gfpmask(). This gfpmask includes GFP_TRANSHUGE and then GFP_HIGHUSER_MOVABLE.
OK.
So where's the bug? I'm inclined to say that it's in ttm. It's taking
I agree that.
a gfp_mask which means "this is the allocation attempt which we are attempting to satisfy" and uses that for its own allocation.
But ttm has no business using that gfp_mask for its own allocation attempt. If anything it should use something like, err,
GFP_KERNEL & ~__GFP_IO & ~__GFP_FS | __GFP_HIGH
although as I mentioned earlier, it would be better to avoid allocation altogether.
Yes, avoiding would be the best.
If not possible, introducing new common helper for changing shrinker control's gfp to valid allocation gfp is better than just open code.
Thanks.
Poor ttm guys - this is a bit of a trap we set for them.
-- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>