Received: by 2002:a25:1506:0:0:0:0:0 with SMTP id 6csp2563566ybv; Mon, 24 Feb 2020 07:29:53 -0800 (PST) X-Google-Smtp-Source: APXvYqwNZvzbU4NuFqcd89jaL4iGBh0sEHtKIONtgEWExF4xW8yndWgErV5iBP4ViWVcRJadZdt4 X-Received: by 2002:a05:6830:1b6b:: with SMTP id d11mr10928891ote.46.1582558193600; Mon, 24 Feb 2020 07:29:53 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1582558193; cv=none; d=google.com; s=arc-20160816; b=UXfr7sv/hK2DZkxuytiK5O70xO/UjMm7xZiWRZvivfXazGOfobVzb46MapC5cTU153 ISnrV9Zi4tq/zpEkD2dzAOCnQc4oaQS26PdHocukDlzoas6rpI4mOdR1U4uM4oHGz0RI K7xsKnBTl2mJxXNCQR5jkUBsZr0h5JAZ1a9GnADjT9L8XxOwP4yGFJAIpbqHRVIupng3 Za9GRFAdOvpPB0I4pk29A25bB9azelm+Tzobwl5BprDNKaMnxgueUuJ361jKzZLW1owD dsTiU2+EFqVmTS032hthlSAX5DQWSah2XI2HVeOw8kyPHzya3cK85n/umc57Dc61vN6q jyLg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding :content-language:in-reply-to:mime-version:user-agent:date :message-id:autocrypt:from:references:cc:to:subject; bh=RzFTfJ7sLIu7JFH5bET1pRD4mHRorMZCQjMhHiJop2A=; b=sFhdjh0w5oWu/e02uIgf7AAZdRjqghR8i+BeRX7mw/KST5gRx15lDh2NpMm6RLNzRT 5ZVPOTo6Exp01w/SyATUeW3e+veRDHXf9JNfvnZOaH4SqIbgdX/GLN1cZLMloF/SzXEQ v9EluTXxideXxxld2V0LgBxXIxfTpAGPkdIQeWqFYb38e2vPaUTBMKBC4f9/fCTQ+98M EFZ5oW6Jjfjeo5lcAY08m9T5IxrTBndXXYYuU67H1o6pD4SwKNIjL86Z45VENCuWU/7M jCoooI/DfpqeZ3p8ZJDkElZubGvG1V3EQt9BkoTv/s9qigTXvUcLBT5IzTKn4nO8yw9H J5wg== 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 x72si4855077oia.194.2020.02.24.07.29.40; Mon, 24 Feb 2020 07:29:53 -0800 (PST) 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 S1727860AbgBXP3N (ORCPT + 99 others); Mon, 24 Feb 2020 10:29:13 -0500 Received: from mx2.suse.de ([195.135.220.15]:49788 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727581AbgBXP3M (ORCPT ); Mon, 24 Feb 2020 10:29:12 -0500 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 2EF5DADBE; Mon, 24 Feb 2020 15:29:10 +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, riel@fb.com 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> 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: <05027092-a43e-756f-4fee-78f29a048ca1@suse.cz> Date: Mon, 24 Feb 2020 16:29:09 +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: <3289dc5e6c4c3174999598d8293adf8ed3e93b57.1582321645.git.riel@surriel.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 2/21/20 10:53 PM, Rik van Riel wrote: > @@ -981,7 +981,9 @@ isolate_migratepages_block(struct compact_control *cc, unsigned long low_pfn, > if (__isolate_lru_page(page, isolate_mode) != 0) > goto isolate_fail; > > - VM_BUG_ON_PAGE(PageCompound(page), page); > + /* The whole page is taken off the LRU; skip the tail pages. */ > + if (PageCompound(page)) > + low_pfn += compound_nr(page) - 1; > > /* Successfully isolated */ > del_page_from_lru_list(page, lruvec, page_lru(page)); This continues by: inc_node_page_state(page, NR_ISOLATED_ANON + page_is_file_cache(page)); I think it now needs to use mod_node_page_state() with hpage_nr_pages(page) otherwise the counter will underflow after the migration? > diff --git a/mm/page_alloc.c b/mm/page_alloc.c > index a36736812596..38c8ddfcecc8 100644 > --- a/mm/page_alloc.c > +++ b/mm/page_alloc.c > @@ -8253,14 +8253,16 @@ struct page *has_unmovable_pages(struct zone *zone, struct page *page, > > /* > * Hugepages are not in LRU lists, but they're movable. > + * THPs are on the LRU, but need to be counted as #small pages. > * We need not scan over tail pages because we don't > * handle each tail page individually in migration. > */ > - if (PageHuge(page)) { > + if (PageTransHuge(page)) { Hmm, PageTransHuge() has VM_BUG_ON() for tail pages, while this code is written so that it can encounter a tail page and skip the rest of the compound page properly. So I would be worried about this. Also PageTransHuge() is basically just a PageHead() so for each non-hugetlbfs compound page this will assume it's a THP, while correctly it should reach the __PageMovable() || PageLRU(page) tests below. So probably this should do something like. if (PageHuge(page) || PageTransCompound(page)) { ... if (PageHuge(page) && !hpage_migration_supported)) return page. if (!PageLRU(head) && !__PageMovable(head)) return page ... > struct page *head = compound_head(page); > unsigned int skip_pages; > > - if (!hugepage_migration_supported(page_hstate(head))) > + if (PageHuge(page) && > + !hugepage_migration_supported(page_hstate(head))) > return page; > > skip_pages = compound_nr(head) - (page - head); >