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=-2.3 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_1 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 7E72AC3F2D2 for ; Fri, 28 Feb 2020 15:23:23 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 479F12469F for ; Fri, 28 Feb 2020 15:23:23 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 479F12469F Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=suse.cz Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id D414C6B0005; Fri, 28 Feb 2020 10:23:22 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id CF18D6B0006; Fri, 28 Feb 2020 10:23:22 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id C06BA6B0007; Fri, 28 Feb 2020 10:23:22 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0134.hostedemail.com [216.40.44.134]) by kanga.kvack.org (Postfix) with ESMTP id A63BB6B0005 for ; Fri, 28 Feb 2020 10:23:22 -0500 (EST) Received: from smtpin30.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay02.hostedemail.com (Postfix) with ESMTP id 391E85DCB for ; Fri, 28 Feb 2020 15:23:22 +0000 (UTC) X-FDA: 76539904644.30.wall86_5e3bd1a2b853 Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin30.hostedemail.com (Postfix) with ESMTP id 0F0C71803FFDD for ; Fri, 28 Feb 2020 15:17:21 +0000 (UTC) X-HE-Tag: wall86_5e3bd1a2b853 X-Filterd-Recvd-Size: 4801 Received: from mx2.suse.de (mx2.suse.de [195.135.220.15]) by imf01.hostedemail.com (Postfix) with ESMTP for ; Fri, 28 Feb 2020 15:17:20 +0000 (UTC) X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.220.254]) by mx2.suse.de (Postfix) with ESMTP id 03ABBAF55; Fri, 28 Feb 2020 15:17:17 +0000 (UTC) Subject: Re: [PATCH 2/2] mm,thp,compaction,cma: allow THP migration for CMA allocations To: Rik van Riel , 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 References: <3289dc5e6c4c3174999598d8293adf8ed3e93b57.1582321645.git.riel@surriel.com> <05027092-a43e-756f-4fee-78f29a048ca1@suse.cz> <81c8d2fa-a8ae-82b8-f359-bba055fbff68@suse.cz> From: Vlastimil Babka Autocrypt: addr=vbabka@suse.cz; prefer-encrypt=mutual; keydata= mQINBFZdmxYBEADsw/SiUSjB0dM+vSh95UkgcHjzEVBlby/Fg+g42O7LAEkCYXi/vvq31JTB KxRWDHX0R2tgpFDXHnzZcQywawu8eSq0LxzxFNYMvtB7sV1pxYwej2qx9B75qW2plBs+7+YB 87tMFA+u+L4Z5xAzIimfLD5EKC56kJ1CsXlM8S/LHcmdD9Ctkn3trYDNnat0eoAcfPIP2OZ+ 9oe9IF/R28zmh0ifLXyJQQz5ofdj4bPf8ecEW0rhcqHfTD8k4yK0xxt3xW+6Exqp9n9bydiy tcSAw/TahjW6yrA+6JhSBv1v2tIm+itQc073zjSX8OFL51qQVzRFr7H2UQG33lw2QrvHRXqD Ot7ViKam7v0Ho9wEWiQOOZlHItOOXFphWb2yq3nzrKe45oWoSgkxKb97MVsQ+q2SYjJRBBH4 8qKhphADYxkIP6yut/eaj9ImvRUZZRi0DTc8xfnvHGTjKbJzC2xpFcY0DQbZzuwsIZ8OPJCc LM4S7mT25NE5kUTG/TKQCk922vRdGVMoLA7dIQrgXnRXtyT61sg8PG4wcfOnuWf8577aXP1x 6mzw3/jh3F+oSBHb/GcLC7mvWreJifUL2gEdssGfXhGWBo6zLS3qhgtwjay0Jl+kza1lo+Cv BB2T79D4WGdDuVa4eOrQ02TxqGN7G0Biz5ZLRSFzQSQwLn8fbwARAQABtCBWbGFzdGltaWwg QmFia2EgPHZiYWJrYUBzdXNlLmN6PokCVAQTAQoAPgIbAwULCQgHAwUVCgkICwUWAgMBAAIe AQIXgBYhBKlA1DSZLC6OmRA9UCJPp+fMgqZkBQJcbbyGBQkH8VTqAAoJECJPp+fMgqZkpGoP /1jhVihakxw1d67kFhPgjWrbzaeAYOJu7Oi79D8BL8Vr5dmNPygbpGpJaCHACWp+10KXj9yz fWABs01KMHnZsAIUytVsQv35DMMDzgwVmnoEIRBhisMYOQlH2bBn/dqBjtnhs7zTL4xtqEcF 1hoUFEByMOey7gm79utTk09hQE/Zo2x0Ikk98sSIKBETDCl4mkRVRlxPFl4O/w8dSaE4eczH LrKezaFiZOv6S1MUKVKzHInonrCqCNbXAHIeZa3JcXCYj1wWAjOt9R3NqcWsBGjFbkgoKMGD usiGabetmQjXNlVzyOYdAdrbpVRNVnaL91sB2j8LRD74snKsV0Wzwt90YHxDQ5z3M75YoIdl byTKu3BUuqZxkQ/emEuxZ7aRJ1Zw7cKo/IVqjWaQ1SSBDbZ8FAUPpHJxLdGxPRN8Pfw8blKY 8mvLJKoF6i9T6+EmlyzxqzOFhcc4X5ig5uQoOjTIq6zhLO+nqVZvUDd2Kz9LMOCYb516cwS/ Enpi0TcZ5ZobtLqEaL4rupjcJG418HFQ1qxC95u5FfNki+YTmu6ZLXy+1/9BDsPuZBOKYpUm 3HWSnCS8J5Ny4SSwfYPH/JrtberWTcCP/8BHmoSpS/3oL3RxrZRRVnPHFzQC6L1oKvIuyXYF rkybPXYbmNHN+jTD3X8nRqo+4Qhmu6SHi3Vq Message-ID: <1094fc21-9104-1410-bc03-f1934dbfcd66@suse.cz> Date: Fri, 28 Feb 2020 16:17:17 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.5.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit 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: On 2/26/20 6:53 PM, Rik van Riel wrote: > On Wed, 2020-02-26 at 10:48 +0100, Vlastimil Babka wrote: >> On 2/25/20 7:44 PM, Rik van Riel wrote: >> >> Uh, is it any different from base pages which have to pass the same >> check? I >> guess the caller could do e.g. lru_add_drain_all() first. > > You are right, it is not different. > > As for lru_add_drain_all(), I wonder at what point that > should happen? Right now it seems to be done in alloc_contig_range(), but rather late. > 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 > > 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. > > If we still see unmovable pages after that, it is cheap > enough to set the page block back to its previous state. 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.