Received: by 2002:a25:d783:0:0:0:0:0 with SMTP id o125csp856150ybg; Thu, 19 Mar 2020 09:57:18 -0700 (PDT) X-Google-Smtp-Source: ADFU+vv7KZdmCuosqAmZtiWEx5OVdE6EoTj/E9S6esSwRg4/WwAqcpn0YrsqrQtOaOIBb3Qnj3v0 X-Received: by 2002:a05:6830:1051:: with SMTP id b17mr3184660otp.157.1584637037849; Thu, 19 Mar 2020 09:57:17 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1584637037; cv=none; d=google.com; s=arc-20160816; b=MV/XZni1lDCwPVfGGLzWK7yGnbWr/B5Gb4cjvZzwRTv/x763NAkNHs8HgLyR7LXpE/ AiAPnRyuNYkA3Hafq4W8vDwTQP2QxBhwiObdBpxnF64sxD1hprW9QVtG4EV67lX7rijx MoSE2c38kiO5rsF1uuST+li4baUBeETuuAN7Q6IcsOAahbndgT0D4zTy6skFc916Z8aK 5qK0xdpjuyTctpPaaE/XPdomX+zq6XcpfpBWrYJ6UX8mm1xxD5oGTwvpeNJ4S0HllKJ/ idafjK80T89YE2zdScGmc80OGrx21ZdDXRrrwtKgyVYpy4y+vqZ/8syyvOewAMrAvmoh 9/8A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:mime-version:user-agent:references :in-reply-to:date:cc:to:from:subject:message-id; bh=PeNS/isn9cCvwq97ZT4WY1ZHrsBZMPXVxi39JjYYbHI=; b=Mq20VvIUyJTHp2omXQjbgDb/1TpyeT3f4UzbxP8QdPkbExO5VdItgqpab52rg5OwJq D2e4Pg9+MYMH5ycj8VDq1Fakd79mv+4XPzSgNJODba9+aJDqounmushZunlh9/tLKBcn uQvAjJ9wXQQFXFp1nbURSbbQBEGgkXKVAM1ipKxyzbXCKkkG28GX3n+jj3Nwdc5IpHoH 0nlwzinm4KGFwFV7OVHoMKgwtjujzEzXNOMjHw2M+aekNIqZhGiZ7Px2ccXLDP1pqP70 +uYj1pvf59h651QsDKEMBqsIhsaFe/wIAuJKcRsjb42H/6SxvAyzehS2I1UwXi1RbAhi 68/A== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id s1si1182340oij.237.2020.03.19.09.57.03; Thu, 19 Mar 2020 09:57:17 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727847AbgCSQ4o (ORCPT + 99 others); Thu, 19 Mar 2020 12:56:44 -0400 Received: from shelob.surriel.com ([96.67.55.147]:56784 "EHLO shelob.surriel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727146AbgCSQ4o (ORCPT ); Thu, 19 Mar 2020 12:56:44 -0400 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 1jEyTD-0007SS-8f; Thu, 19 Mar 2020 12:56:35 -0400 Message-ID: <3f75f55dc6a9b4dfd3c6ac808c370bfd91d1554a.camel@surriel.com> Subject: Re: [PATCH] mm: hugetlb: fix hugetlb_cma_reserve() if CONFIG_NUMA isn't set From: Rik van Riel To: Michal Hocko , Roman Gushchin , Aslan Bakirov Cc: Andrew Morton , linux-mm@kvack.org, kernel-team@fb.com, linux-kernel@vger.kernel.org, Andreas Schaufler , Mike Kravetz , Guido =?ISO-8859-1?Q?G=FCnther?= , Naresh Kamboju Date: Thu, 19 Mar 2020 12:56:34 -0400 In-Reply-To: <20200319161644.GH20800@dhcp22.suse.cz> References: <20200318153424.3202304-1-guro@fb.com> <20200318161625.GR21362@dhcp22.suse.cz> <20200318175529.GA6263@carbon.dhcp.thefacebook.com> <20200319161644.GH20800@dhcp22.suse.cz> Content-Type: multipart/signed; micalg="pgp-sha256"; protocol="application/pgp-signature"; boundary="=-xqGcAAkovkjaAH5al2Q2" User-Agent: Evolution 3.34.3 (3.34.3-1.fc31) MIME-Version: 1.0 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org --=-xqGcAAkovkjaAH5al2Q2 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Thu, 2020-03-19 at 17:16 +0100, Michal Hocko wrote: >=20 > This is not the first time HAVE_MEMBLOCK_NODE_MAP has been > problematic. > I might be missing something but I really do not get why do we really > need it these days. As for !NUMA, I suspect we can make it generate > the > right thing when !NUMA. We're working on a different fix now. It looks like cma_declare_contiguous calls memblock_phys_alloc_range, which calls memblock_alloc_range_nid, which takes a NUMA node as one of its arguments. Aslan is looking at simply adding a cma_declare_contiguous_nid, which also takes a NUMA node ID as an argument. At that point we can simply leave CMA free to allocate from anywhere in each NUMA node, which by default already happens from the top down. That should be the nicer long term fix to this issue. --=20 All Rights Reversed. --=-xqGcAAkovkjaAH5al2Q2 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- iQEzBAABCAAdFiEEKR73pCCtJ5Xj3yADznnekoTE3oMFAl5zpEIACgkQznnekoTE 3oOzXwf+KFp0GJtUWncQg/fSVDlVuX0CDEUh2qJkjwZG8CXXZ7RetNSgWwJBh6NZ 0/3UTuEFRIvJ+URQ1dSxSD7wxtuJxv7b0E+NR7Q0OgmhMbtxeCyLtecwazcM2nym 4THHUWVFI1gvV22eMA25Olw5os/GrC09+LvQdr3U+fPkk6IJplWgcSfXAII04YLG 6uLoIV0cSwfjBAPmdj4uOji9u/m+urLqCnMRA0GGHAV0GfAG9jHOcYNiDqO6phjE 39RRgL0D4k5WaCTIcxCSfHJ9GotJBi2zFapBFB5YkYAjXU+PcaATxV08LgSyz6lK /aw2p4uFDgxdBFEXYjdHyHP6+XVZeA== =29Xz -----END PGP SIGNATURE----- --=-xqGcAAkovkjaAH5al2Q2--