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=-0.8 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS 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 02915C10DCE for ; Fri, 6 Mar 2020 22:22:18 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id A6D1420674 for ; Fri, 6 Mar 2020 22:22:17 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org A6D1420674 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=surriel.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 0F61F6B0003; Fri, 6 Mar 2020 17:22:17 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 0A6A76B0006; Fri, 6 Mar 2020 17:22:17 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id ED79F6B0007; Fri, 6 Mar 2020 17:22:16 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0217.hostedemail.com [216.40.44.217]) by kanga.kvack.org (Postfix) with ESMTP id D3CF86B0003 for ; Fri, 6 Mar 2020 17:22:16 -0500 (EST) Received: from smtpin14.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay02.hostedemail.com (Postfix) with ESMTP id 8372034A3 for ; Fri, 6 Mar 2020 22:22:16 +0000 (UTC) X-FDA: 76566361872.14.smile40_30f1345200040 X-HE-Tag: smile40_30f1345200040 X-Filterd-Recvd-Size: 3735 Received: from shelob.surriel.com (shelob.surriel.com [96.67.55.147]) by imf34.hostedemail.com (Postfix) with ESMTP for ; Fri, 6 Mar 2020 22:22:16 +0000 (UTC) Received: from imladris.surriel.com ([96.67.55.152]) by shelob.surriel.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.92.3) (envelope-from ) id 1jALM9-0002eb-Ec; Fri, 06 Mar 2020 17:22:09 -0500 Message-ID: Subject: Re: [PATCH] mm,cma: remove pfn_range_valid_contig From: Rik van Riel To: Andrew Morton Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org, kernel-team@fb.com, Anshuman Khandual , Mel Gorman , Vlastimil Babka , Qian Cai , Roman Gushchin Date: Fri, 06 Mar 2020 17:22:08 -0500 In-Reply-To: <20200306170647.455a2db3@imladris.surriel.com> References: <20200306170647.455a2db3@imladris.surriel.com> Content-Type: multipart/signed; micalg="pgp-sha256"; protocol="application/pgp-signature"; boundary="=-v499DhLZoYA5eMsPwnq4" User-Agent: Evolution 3.34.3 (3.34.3-1.fc31) MIME-Version: 1.0 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: --=-v499DhLZoYA5eMsPwnq4 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Fri, 2020-03-06 at 17:06 -0500, Rik van Riel wrote: > The function pfn_range_valid_contig checks whether all memory in the > target area is free. This causes unnecessary CMA failures, since > alloc_contig_range will migrate movable memory out of a target range, > and has its own sanity check early on in has_unmovable_pages, which > is called from start_isolate_page_range & set_migrate_type_isolate. >=20 > Relying on that has_unmovable_pages call simplifies the CMA code and > results in an increased success rate of CMA allocations. Thinking about this some more, could we get away with entirely removing alloc_contig_pages, and simply having the hugetlb code use cma_alloc? That might be simpler still. It also seems like it could make the success rate of=20 1GB hugepage allocation much more predictable, because the kernel will place only movable memory allocations inside the CMA area, and we would never try to allocate a 1GB huge page from a 1GB memory area with unmovable pages. It would be possible for the code in hugetlb_init() to=20 invoke the cma setup code as needed, to set aside an=20 appropriate amount of memory for movable allocations (and later CMA 1GB hugepages) only. Then again, if the allocation reliability ends up being eg. 90% instead of 100%, we may need some way to set up the memory pool for CMA hugepage allocation a little larger, and not size it automatically to the desired number of hugepages (with nothing to spare). An explicit hugepage_cma=3DnG option would cover that. Thoughts? --=20 All Rights Reversed. --=-v499DhLZoYA5eMsPwnq4 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- iQEzBAABCAAdFiEEKR73pCCtJ5Xj3yADznnekoTE3oMFAl5izREACgkQznnekoTE 3oNtfQf+JOhaeaxAe2v88M+rVpJmW3EdtDjD/b6mvN6yRCAWlLHKmue+APtFKnxA qYRpSdGM+qB7/wc8rcnHbcmyKEQQ6zc2+ZO1XPv1COkREcyH0k07SLb3q2ei+TTi qloOexBM/hfvoCTWwogkrtZPyck9oJJAV0XqeJZKe9RssiLapLbogkjT0wad8rne cQ3AdSrUDcGljCjXofIh3Fs84YFxb/WTI3PzP2eZZJeOMnIhDCEyp6aae4sMoFpb C/RrGNQwltSUoh89eJkHtTZ1PAhz2L0wdJ/Jb6NawJhiMaNP7O/LbE2pPaIlfdfg mcSRhTYzKOk+Obvgh189A+vWpRv/iQ== =Qwq0 -----END PGP SIGNATURE----- --=-v499DhLZoYA5eMsPwnq4--