From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-3.8 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SIGNED_OFF_BY, SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 45BC2C2D0E9 for ; Thu, 2 Apr 2020 04:10:31 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 0B72C2074D for ; Thu, 2 Apr 2020 04:10:31 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=kernel.org header.i=@kernel.org header.b="cZoxgfoD" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 0B72C2074D Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=linux-foundation.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id AF49C8E0080; Thu, 2 Apr 2020 00:10:30 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id AA56F8E000D; Thu, 2 Apr 2020 00:10:30 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 8FDCD8E0080; Thu, 2 Apr 2020 00:10:30 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0166.hostedemail.com [216.40.44.166]) by kanga.kvack.org (Postfix) with ESMTP id 72D348E000D for ; Thu, 2 Apr 2020 00:10:30 -0400 (EDT) Received: from smtpin15.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay04.hostedemail.com (Postfix) with ESMTP id 48EE245B3 for ; Thu, 2 Apr 2020 04:10:30 +0000 (UTC) X-FDA: 76661588220.15.drink78_5bae61087df57 X-HE-Tag: drink78_5bae61087df57 X-Filterd-Recvd-Size: 3581 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by imf17.hostedemail.com (Postfix) with ESMTP for ; Thu, 2 Apr 2020 04:10:29 +0000 (UTC) Received: from localhost.localdomain (c-73-231-172-41.hsd1.ca.comcast.net [73.231.172.41]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id C9504208FE; Thu, 2 Apr 2020 04:10:28 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1585800629; bh=PT2vno5jkFa2s88mZy80mI5BApAJgCYVNO6My2U15hE=; h=Date:From:To:Subject:In-Reply-To:From; b=cZoxgfoDB+K4Lu//zVZEejNvqyqDmxSQP2KhCBZ7LEgtqpBM//cSMu8499suOE10y 1TlQQ3IDAdIz2+rFliz/lggqKSA3Drx/cIXGP75a27Plup5vgUGu9AepWvgUyZ4jmN vyQp52WZW4E1wDGQ4P7Fv7+JGsQVzf+ZDQ5L32l0= Date: Wed, 01 Apr 2020 21:10:28 -0700 From: Andrew Morton To: aarcange@redhat.com, akpm@linux-foundation.org, js1304@gmail.com, linux-mm@kvack.org, mgorman@techsingularity.net, mhocko@kernel.org, mm-commits@vger.kernel.org, riel@surriel.com, rientjes@google.com, torvalds@linux-foundation.org, vbabka@suse.cz, ziy@nvidia.com Subject: [patch 128/155] mm,compaction,cma: add alloc_contig flag to compact_control Message-ID: <20200402041028.KuUPt4-SW%akpm@linux-foundation.org> In-Reply-To: <20200401210155.09e3b9742e1c6e732f5a7250@linux-foundation.org> User-Agent: s-nail v14.8.16 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: From: Rik van Riel Subject: mm,compaction,cma: add alloc_contig flag to compact_control Patch series "fix THP migration for CMA allocations", v2. Transparent huge pages are allocated with __GFP_MOVABLE, and can end up in CMA memory blocks. Transparent huge pages also have most of the infrastructure in place to allow migration. However, a few pieces were missing, causing THP migration to fail when attempting to use CMA to allocate 1GB hugepages. With these patches in place, THP migration from CMA blocks seems to work, both for anonymous THPs and for tmpfs/shmem THPs. This patch (of 2): Add information to struct compact_control to indicate that the allocator would really like to clear out this specific part of memory, used by for example CMA. Link: http://lkml.kernel.org/r/20200227213238.1298752-1-riel@surriel.com Signed-off-by: Rik van Riel Reviewed-by: Vlastimil Babka Cc: Andrea Arcangeli Cc: David Rientjes Cc: Mel Gorman Cc: Michal Hocko Cc: Zi Yan Cc: Joonsoo Kim Signed-off-by: Andrew Morton --- mm/internal.h | 1 + mm/page_alloc.c | 1 + 2 files changed, 2 insertions(+) --- a/mm/internal.h~mmcompactioncma-add-alloc_contig-flag-to-compact_control +++ a/mm/internal.h @@ -229,6 +229,7 @@ struct compact_control { bool whole_zone; /* Whole zone should/has been scanned */ bool contended; /* Signal lock or sched contention */ bool rescan; /* Rescanning the same pageblock */ + bool alloc_contig; /* alloc_contig_range allocation */ }; /* --- a/mm/page_alloc.c~mmcompactioncma-add-alloc_contig-flag-to-compact_control +++ a/mm/page_alloc.c @@ -8400,6 +8400,7 @@ int alloc_contig_range(unsigned long sta .ignore_skip_hint = true, .no_set_skip_hint = true, .gfp_mask = current_gfp_context(gfp_mask), + .alloc_contig = true, }; INIT_LIST_HEAD(&cc.migratepages); _