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=-18.7 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, INCLUDES_CR_TRAILER,INCLUDES_PATCH,MAILING_LIST_MULTI,NICE_REPLY_A, SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED,USER_AGENT_SANE_1 autolearn=unavailable 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 1A5FAC433FE for ; Thu, 3 Dec 2020 16:28:19 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id B903D221F5 for ; Thu, 3 Dec 2020 16:28:18 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1731256AbgLCQ2F (ORCPT ); Thu, 3 Dec 2020 11:28:05 -0500 Received: from us-smtp-delivery-124.mimecast.com ([216.205.24.124]:52464 "EHLO us-smtp-delivery-124.mimecast.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727518AbgLCQ2E (ORCPT ); Thu, 3 Dec 2020 11:28:04 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1607012798; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=FXnZplMMKGwZ14qGf4Awkf5MDG2sv4VomdvDsZTHm1Q=; b=dgjeypkbkpy7zbgs/aI/ocJvOhnnhNT/FV3fhUm/uok5NbvhCUpIDK3JeQkrT44eXK6q3f HtucH8KXgPcdgTiIxx09cb0cZc+HdA3Um5Qz/2ZCsgApE6jtT23Sb5ZA1T/mwkl/G6729p D2Ct1dz7YkpSopaQMAx0cnem3BXySH8= Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-227-PckhPSH8Mr2aq2UqFYAc_Q-1; Thu, 03 Dec 2020 11:26:36 -0500 X-MC-Unique: PckhPSH8Mr2aq2UqFYAc_Q-1 Received: from smtp.corp.redhat.com (int-mx03.intmail.prod.int.phx2.redhat.com [10.5.11.13]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 40E37800D55; Thu, 3 Dec 2020 16:26:34 +0000 (UTC) Received: from [10.36.113.250] (ovpn-113-250.ams2.redhat.com [10.36.113.250]) by smtp.corp.redhat.com (Postfix) with ESMTP id D2E2B60854; Thu, 3 Dec 2020 16:26:32 +0000 (UTC) Subject: Re: [PATCH] mm/page_isolation: do not isolate the max order page To: Vlastimil Babka , Muchun Song , akpm@linux-foundation.org Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org, Joonsoo Kim References: <20201202122114.75316-1-songmuchun@bytedance.com> <1505b548-968b-2053-fd17-0cc4ae240a2f@suse.cz> From: David Hildenbrand Organization: Red Hat GmbH Message-ID: <29022300-6d8e-0532-7abc-6d11ab1db04a@redhat.com> Date: Thu, 3 Dec 2020 17:26:31 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.4.0 MIME-Version: 1.0 In-Reply-To: <1505b548-968b-2053-fd17-0cc4ae240a2f@suse.cz> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.79 on 10.5.11.13 Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 03.12.20 01:03, Vlastimil Babka wrote: > On 12/2/20 1:21 PM, Muchun Song wrote: >> The max order page has no buddy page and never merge to other order. >> So isolating and then freeing it is pointless. >> >> Signed-off-by: Muchun Song > > Acked-by: Vlastimil Babka > >> --- >> mm/page_isolation.c | 2 +- >> 1 file changed, 1 insertion(+), 1 deletion(-) >> >> diff --git a/mm/page_isolation.c b/mm/page_isolation.c >> index a254e1f370a3..bddf788f45bf 100644 >> --- a/mm/page_isolation.c >> +++ b/mm/page_isolation.c >> @@ -88,7 +88,7 @@ static void unset_migratetype_isolate(struct page *page, unsigned migratetype) >> */ >> if (PageBuddy(page)) { >> order = buddy_order(page); >> - if (order >= pageblock_order) { >> + if (order >= pageblock_order && order < MAX_ORDER - 1) { >> pfn = page_to_pfn(page); >> buddy_pfn = __find_buddy_pfn(pfn, order); >> buddy = page + (buddy_pfn - pfn); > > Hm I wonder if order == MAX_ORDER - 1, then the buddy can actually be a > !pfn_valid() in some corner case? pfn_valid_within(buddy_pfn) that follows would > only catch it on archs with holes in zone. Then is_migrate_isolate_page(buddy) > might access an invalid buddy. So this might be actually a bug fix and not just > optimization, just the bug hasn't been observed in practice. I think we have no users that isolate/unisolate close to holes. CMA regions are properly aligned (to max of page_order / max_order_nr_pages) and don't contain holes. virtio-mem does not apply as it knows its range has no holes. gigantic pages are aligned naturally and we check that there are no holes upfront. There are no other users. I don't see a need for stable/fixes. -- Thanks, David / dhildenb