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=-11.6 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, INCLUDES_PATCH,MAILING_LIST_MULTI,SIGNED_OFF_BY,SPF_HELO_NONE,SPF_PASS, USER_AGENT_SANE_1 autolearn=ham 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 214F0C433E0 for ; Wed, 29 Jul 2020 10:48:09 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id D59EA207E8 for ; Wed, 29 Jul 2020 10:48:08 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b="RPWPuGqr" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org D59EA207E8 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=redhat.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 469E76B0003; Wed, 29 Jul 2020 06:48:08 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 419906B0005; Wed, 29 Jul 2020 06:48:08 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 32FD96B0006; Wed, 29 Jul 2020 06:48:08 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0236.hostedemail.com [216.40.44.236]) by kanga.kvack.org (Postfix) with ESMTP id 1C80E6B0003 for ; Wed, 29 Jul 2020 06:48:08 -0400 (EDT) Received: from smtpin27.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay02.hostedemail.com (Postfix) with ESMTP id 9A57DA9430 for ; Wed, 29 Jul 2020 10:48:07 +0000 (UTC) X-FDA: 77090788614.27.fan00_150b1ef26f71 Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin27.hostedemail.com (Postfix) with ESMTP id 759202C8D4E for ; Wed, 29 Jul 2020 10:48:07 +0000 (UTC) X-HE-Tag: fan00_150b1ef26f71 X-Filterd-Recvd-Size: 5182 Received: from us-smtp-delivery-74.mimecast.com (us-smtp-delivery-74.mimecast.com [63.128.21.74]) by imf48.hostedemail.com (Postfix) with ESMTP for ; Wed, 29 Jul 2020 10:48:06 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1596019686; 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: in-reply-to:in-reply-to:references:references; bh=Nb/oG6MtRg7ZezXWKteZXhsfM84O+Ip9PKe2JE7RZUo=; b=RPWPuGqrDnegS8ZOd9pCA1BWfeoLA8hrulyao+aEle1u/gyb0AeFH2p/6lP5pgxOyh+BmR 9A9vDLzAQsXP4CyvdijgYDNWZAGVRfjm6B6LgLQSF7E7vMu2Jm9YB2Kc4EYOU9eaB3JFqT qhIBY/mPvo4d/g+z1LJsABdOIoa7gxo= 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-448-o_VbQsfvPlSCfQQ6kserAw-1; Wed, 29 Jul 2020 06:48:04 -0400 X-MC-Unique: o_VbQsfvPlSCfQQ6kserAw-1 Received: from smtp.corp.redhat.com (int-mx05.intmail.prod.int.phx2.redhat.com [10.5.11.15]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 656EE79EC6; Wed, 29 Jul 2020 10:48:03 +0000 (UTC) Received: from localhost (ovpn-12-32.pek2.redhat.com [10.72.12.32]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 203867191C; Wed, 29 Jul 2020 10:47:55 +0000 (UTC) Date: Wed, 29 Jul 2020 18:47:53 +0800 From: Baoquan He To: David Hildenbrand Cc: linux-kernel@vger.kernel.org, virtualization@lists.linux-foundation.org, linux-mm@kvack.org, Andrew Morton , Michal Hocko , "Michael S . Tsirkin" Subject: Re: [PATCH v1 1/6] mm/page_alloc: tweak comments in has_unmovable_pages() Message-ID: <20200729104753.GF14854@MiWiFi-R3L-srv> References: <20200630142639.22770-1-david@redhat.com> <20200630142639.22770-2-david@redhat.com> <20200728134826.GC14854@MiWiFi-R3L-srv> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) X-Scanned-By: MIMEDefang 2.79 on 10.5.11.15 X-Rspamd-Queue-Id: 759202C8D4E X-Spamd-Result: default: False [0.00 / 100.00] X-Rspamd-Server: rspam03 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 07/28/20 at 04:07pm, David Hildenbrand wrote: > On 28.07.20 15:48, Baoquan He wrote: > > On 06/30/20 at 04:26pm, David Hildenbrand wrote: > >> Let's move the split comment regarding bootmem allocations and memory > >> holes, especially in the context of ZONE_MOVABLE, to the PageReserved() > >> check. > >> > >> Cc: Andrew Morton > >> Cc: Michal Hocko > >> Cc: Michael S. Tsirkin > >> Signed-off-by: David Hildenbrand > >> --- > >> mm/page_alloc.c | 22 ++++++---------------- > >> 1 file changed, 6 insertions(+), 16 deletions(-) > >> > >> diff --git a/mm/page_alloc.c b/mm/page_alloc.c > >> index 48eb0f1410d47..bd3ebf08f09b9 100644 > >> --- a/mm/page_alloc.c > >> +++ b/mm/page_alloc.c > >> @@ -8207,14 +8207,6 @@ struct page *has_unmovable_pages(struct zone *zone, struct page *page, > >> unsigned long iter = 0; > >> unsigned long pfn = page_to_pfn(page); > >> > >> - /* > >> - * TODO we could make this much more efficient by not checking every > >> - * page in the range if we know all of them are in MOVABLE_ZONE and > >> - * that the movable zone guarantees that pages are migratable but > >> - * the later is not the case right now unfortunatelly. E.g. movablecore > >> - * can still lead to having bootmem allocations in zone_movable. > >> - */ > >> - > >> if (is_migrate_cma_page(page)) { > >> /* > >> * CMA allocations (alloc_contig_range) really need to mark > >> @@ -8233,6 +8225,12 @@ struct page *has_unmovable_pages(struct zone *zone, struct page *page, > >> > >> page = pfn_to_page(pfn + iter); > >> > >> + /* > >> + * Both, bootmem allocations and memory holes are marked > >> + * PG_reserved and are unmovable. We can even have unmovable > >> + * allocations inside ZONE_MOVABLE, for example when > >> + * specifying "movable_core". > > ~~~~ should be 'movablecore', we don't > > have kernel parameter 'movable_core'. > > Agreed! > > > > > Otherwise, this looks good to me. Esp the code comment at below had been > > added very long time ago and obsolete. > > > > Reviewed-by: Baoquan He > > > > By the way, David, do you know what is the situation of having unmovable > > allocations inside ZONE_MOVABLE when specifying 'movablecore'? I quickly > > went through find_zone_movable_pfns_for_nodes(), but didn't get why. > > Could you tell a little more detail about it? > > As far as I understand, it can happen that we have memblock allocations > during boot that fall into an area the kernel later configures to span > the movable zone (via movable_core). Seems yes, thanks a lot. Wondering who is still using movablecore|kernelcore in what use case.