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 BE1C1C3F2D3 for ; Sun, 1 Mar 2020 02:24:24 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 871DE24649 for ; Sun, 1 Mar 2020 02:24:24 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 871DE24649 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 08B9F6B0005; Sat, 29 Feb 2020 21:24:24 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 03CAA6B0006; Sat, 29 Feb 2020 21:24:23 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id EBAB16B0007; Sat, 29 Feb 2020 21:24:23 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0004.hostedemail.com [216.40.44.4]) by kanga.kvack.org (Postfix) with ESMTP id CED986B0005 for ; Sat, 29 Feb 2020 21:24:23 -0500 (EST) Received: from smtpin04.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay04.hostedemail.com (Postfix) with ESMTP id 81759282A for ; Sun, 1 Mar 2020 02:24:23 +0000 (UTC) X-FDA: 76545199206.04.flag77_43689f43fe718 X-HE-Tag: flag77_43689f43fe718 X-Filterd-Recvd-Size: 3976 Received: from shelob.surriel.com (shelob.surriel.com [96.67.55.147]) by imf25.hostedemail.com (Postfix) with ESMTP for ; Sun, 1 Mar 2020 02:24:23 +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 1j8EH7-00016k-Gx; Sat, 29 Feb 2020 21:24:13 -0500 Message-ID: Subject: Re: [PATCH 2/2] mm,thp,compaction,cma: allow THP migration for CMA allocations From: Rik van Riel To: Vlastimil Babka , linux-kernel@vger.kernel.org Cc: kernel-team@fb.com, akpm@linux-foundation.org, linux-mm@kvack.org, mhocko@kernel.org, mgorman@techsingularity.net, rientjes@google.com, aarcange@redhat.com Date: Sat, 29 Feb 2020 21:24:09 -0500 In-Reply-To: <1094fc21-9104-1410-bc03-f1934dbfcd66@suse.cz> References: <3289dc5e6c4c3174999598d8293adf8ed3e93b57.1582321645.git.riel@surriel.com> <05027092-a43e-756f-4fee-78f29a048ca1@suse.cz> <81c8d2fa-a8ae-82b8-f359-bba055fbff68@suse.cz> <1094fc21-9104-1410-bc03-f1934dbfcd66@suse.cz> Content-Type: multipart/signed; micalg="pgp-sha256"; protocol="application/pgp-signature"; boundary="=-uhw2MaE8So4ibiAndE8G" 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: --=-uhw2MaE8So4ibiAndE8G Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Fri, 2020-02-28 at 16:17 +0100, Vlastimil Babka wrote: > On 2/26/20 6:53 PM, Rik van Riel wrote: > >=20 > > It appears that the order in which things are done does > > not really provide a good moment: > > 1) decide to attempt allocating a range of memory > > 2) scan each page block for unmovable pages > > 3) if no unmovable pages are found, mark the page block > > MIGRATE_ISOLATE > >=20 > > I wonder if we should do things the opposite way, first > > marking the page block MIGRATE_ISOLATE (to prevent new > > allocations), then scanning it, and calling lru_add_drain_all > > if we encounter a page that looks like it could benefit from > > that. > >=20 > > If we still see unmovable pages after that, it is cheap > > enough to set the page block back to its previous state. >=20 > Yeah seems like the whole has_unmovable_pages() thing isn't much > useful > here. It might prevent some unnecessary action like isolating > something, > then finding non-movable page and rolling back the isolation. But > maybe > it's not worth the savings, and also has_unmovable_pages() being > false > doesn't guarantee succeed in the actual isolate+migrate attempt. And > if > it can cause a false negative due to lru pages not drained, then it's > actually worse than if it wasn't called at all. We'll experiment with that, and see how often it is an issue in practice. If this aspect of the code needs improving, I suspect Roman and I will find it soon enough. --=20 All Rights Reversed. --=-uhw2MaE8So4ibiAndE8G Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- iQEzBAABCAAdFiEEKR73pCCtJ5Xj3yADznnekoTE3oMFAl5bHMkACgkQznnekoTE 3oPf1QgAubWJCIPdZBomnqtqeXqkQcsFhxmG9DpikmTRcoNXX7zWbxFMPVk3KyyZ hOn+5R1mudluuIYV00LcFYSh1tFi6HDyf6Z/RztnXGykpe9s0ggFSe1tBJEM/AYN J7MYW9M0gFBfSHpi+pAmS/dkOVb5LtVtuDD3DZDd1cYs8vRLqPnpTmSdSgkUkl31 L9t2XJc6KmPdgXTwlv3+CvzfrVJbD15RRRWvw9ThAdsft/6n4RXSOR6BIovTBBqT FZCxcn6fk60dZPCvo5+IEjR7u24t67vQjX+sOFNRwxw3N9wg+9eO2agPcDfDBCUc qGvK2lxwzLcDcqhgHKrMvOye+aPmqA== =69L+ -----END PGP SIGNATURE----- --=-uhw2MaE8So4ibiAndE8G--