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=BAYES_00, 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 680A7C43461 for ; Wed, 9 Sep 2020 13:49:20 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id D7A4D20639 for ; Wed, 9 Sep 2020 13:49:17 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org D7A4D20639 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 361B4900005; Wed, 9 Sep 2020 09:49:17 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 2E94E900004; Wed, 9 Sep 2020 09:49:17 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 1B21F900005; Wed, 9 Sep 2020 09:49:17 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0179.hostedemail.com [216.40.44.179]) by kanga.kvack.org (Postfix) with ESMTP id 02644900004 for ; Wed, 9 Sep 2020 09:49:16 -0400 (EDT) Received: from smtpin19.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay03.hostedemail.com (Postfix) with ESMTP id BB23D8248047 for ; Wed, 9 Sep 2020 13:49:16 +0000 (UTC) X-FDA: 77243654712.19.chalk52_5c1707c270dd Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin19.hostedemail.com (Postfix) with ESMTP id 731F81AD1B1 for ; Wed, 9 Sep 2020 13:49:16 +0000 (UTC) X-HE-Tag: chalk52_5c1707c270dd X-Filterd-Recvd-Size: 4992 Received: from shelob.surriel.com (shelob.surriel.com [96.67.55.147]) by imf46.hostedemail.com (Postfix) with ESMTP for ; Wed, 9 Sep 2020 13:49:15 +0000 (UTC) Received: from imladris.surriel.com ([96.67.55.152]) by shelob.surriel.com with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94) (envelope-from ) id 1kG0TE-0004A3-Qr; Wed, 09 Sep 2020 09:49:08 -0400 Message-ID: <4923e178c12f38148a2620ba31fcded349e555fb.camel@surriel.com> Subject: Re: [RFC PATCH 00/16] 1GB THP support on x86_64 From: Rik van Riel To: David Hildenbrand , Michal Hocko Cc: Zi Yan , Roman Gushchin , "Kirill A. Shutemov" , linux-mm@kvack.org, "Kirill A . Shutemov" , Matthew Wilcox , Shakeel Butt , Yang Shi , David Nellans , linux-kernel@vger.kernel.org Date: Wed, 09 Sep 2020 09:49:08 -0400 In-Reply-To: <6135d2c5-2a74-6ca8-4b3b-8ceb25c0d4b1@redhat.com> References: <20200902180628.4052244-1-zi.yan@sent.com> <20200903142300.bjq2um5y5nwocvar@box> <20200903163020.GG60440@carbon.dhcp.thefacebook.com> <8e677ead-206d-08dd-d73e-569bd3803e3b@redhat.com> <7E20392E-5ED7-4C22-9555-F3BAABF3CBE9@nvidia.com> <20200908143503.GE26850@dhcp22.suse.cz> <7ed82cb06074b30c2956638082c515fb179f69a3.camel@surriel.com> <20200909070445.GA7348@dhcp22.suse.cz> <054d02f3b34d9946905929ff268b685c91494b3e.camel@surriel.com> <6135d2c5-2a74-6ca8-4b3b-8ceb25c0d4b1@redhat.com> Content-Type: multipart/signed; micalg="pgp-sha256"; protocol="application/pgp-signature"; boundary="=-wpHNEj3y3TgmHwDLJS21" User-Agent: Evolution 3.34.4 (3.34.4-1.fc31) MIME-Version: 1.0 X-Rspamd-Queue-Id: 731F81AD1B1 X-Spamd-Result: default: False [0.00 / 100.00] X-Rspamd-Server: rspam02 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: --=-wpHNEj3y3TgmHwDLJS21 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, 2020-09-09 at 15:43 +0200, David Hildenbrand wrote: > On 09.09.20 15:19, Rik van Riel wrote: > > On Wed, 2020-09-09 at 09:04 +0200, Michal Hocko wrote: > >=20 > > > That CMA has to be pre-reserved, right? That requires a > > > configuration. > >=20 > > To some extent, yes. > >=20 > > However, because that pool can be used for movable > > 4kB and 2MB > > pages as well as for 1GB pages, it would be easy to just set > > the size of that pool to eg. 1/3 or even 1/2 of memory for every > > system. > >=20 > > It isn't like the pool needs to be the exact right size. We > > just need to avoid the "highmem problem" of having too little > > memory for kernel allocations. > >=20 >=20 > I am not sure I like the trend towards CMA that we are seeing, > reserving > huge buffers for specific users (and eventually even doing it > automatically). >=20 > What we actually want is ZONE_MOVABLE with relaxed guarantees, such > that > anybody who requires large, unmovable allocations can use it. >=20 > I once played with the idea of having ZONE_PREFER_MOVABLE, which > a) Is the primary choice for movable allocations > b) Is allowed to contain unmovable allocations (esp., gigantic pages) > c) Is the fallback for ZONE_NORMAL for unmovable allocations, instead > of > running out of memory >=20 > If someone messes up the zone ratio, issues known from zone > imbalances > are avoided - large allocations simply become less likely to succeed. > In > contrast to ZONE_MOVABLE, memory offlining is not guaranteed to work. I really like that idea. This will be easier to deal with than a "just the right size" CMA area, and seems like it would be pretty forgiving in both directions. Keeping unmovable allocations contained to one part of memory should also make compaction within the ZONE_PREFER_MOVABLE area a lot easier than compaction for higher order allocations is today. I suspect your proposal solves a lot of issues at once. For (c) from your proposal, we could even claim a whole 2MB or even 1GB area at once for unmovable allocations, keeping those contained in a limited amount of physical memory again, to make life easier on compaction. --=20 All Rights Reversed. --=-wpHNEj3y3TgmHwDLJS21 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- iQEzBAABCAAdFiEEKR73pCCtJ5Xj3yADznnekoTE3oMFAl9Y3VQACgkQznnekoTE 3oMMdwgAkZ9yHAJX87rT4KEdtozUgeiv+oJmpMGrFoxuLJusQjDHWmoH/cZxeUKa LAyR1o25+vHitFDI8jwBSrK/koD7+aA7g4IWD1yvm+MzMLRE1y3O2mpdT5Py2P/R p3zFYlMWaVnons/88lpBVXg4s25BUo1l8oU3Zpo1nIbW6gAW0GLT4k3HrgT1eMoU q9FGjN5fg/COFrfFMkxXheD6g3V6AwSo/7/4jSccaeyxOmyf9D+hiCLYkWOFNvg7 9oz/5K3dekoWR88c5C6hTrr69D32grG8SRk6iqsGAa7CG/HoYFnePOLN7BcI7Wp5 BJ18+VOF8ozRMrFAuvBoSH3ZVOmPhg== =+JlE -----END PGP SIGNATURE----- --=-wpHNEj3y3TgmHwDLJS21--