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=-7.3 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,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 F3864C56202 for ; Thu, 26 Nov 2020 18:29:43 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 4945621D7F for ; Thu, 26 Nov 2020 18:29:43 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b="Y5rQYQXF" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 4945621D7F 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 71F8F6B005D; Thu, 26 Nov 2020 13:29:42 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 6CF8B6B0070; Thu, 26 Nov 2020 13:29:42 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 5BE4F6B0072; Thu, 26 Nov 2020 13:29:42 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0148.hostedemail.com [216.40.44.148]) by kanga.kvack.org (Postfix) with ESMTP id 3DA496B005D for ; Thu, 26 Nov 2020 13:29:42 -0500 (EST) Received: from smtpin06.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay05.hostedemail.com (Postfix) with ESMTP id 087EF181AEF1E for ; Thu, 26 Nov 2020 18:29:42 +0000 (UTC) X-FDA: 77527407804.06.skirt64_2e0c53d27381 Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin06.hostedemail.com (Postfix) with ESMTP id D5D201004C654 for ; Thu, 26 Nov 2020 18:29:41 +0000 (UTC) X-HE-Tag: skirt64_2e0c53d27381 X-Filterd-Recvd-Size: 4155 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [63.128.21.124]) by imf44.hostedemail.com (Postfix) with ESMTP for ; Thu, 26 Nov 2020 18:29:40 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1606415380; 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=Dt5+0Amx9XqMpkDRqxtwE80sB6LlnzBoDhEoiCtsP50=; b=Y5rQYQXFJh9ACuLl5OBp/04RH2y4MhLHmdS/jzLEQK5T9gFPFIafSJQi84+X7Ty8DAneva ssQ98Hko7ixcVDCLeaA+MlMoz2zGsBTbLnSlKha4xxWjE7nK1WzDJ4zp5sZFuTCYQIWZXI S+jMExgROMlMeKIx6ZBne5ATqZSWdTs= 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-304-fGCv3kwxN4CgxN9pTmDxfQ-1; Thu, 26 Nov 2020 13:29:38 -0500 X-MC-Unique: fGCv3kwxN4CgxN9pTmDxfQ-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 44F9F8064B3; Thu, 26 Nov 2020 18:29:31 +0000 (UTC) Received: from mail (ovpn-112-118.rdu2.redhat.com [10.10.112.118]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 1A02C5D6AC; Thu, 26 Nov 2020 18:29:31 +0000 (UTC) Date: Thu, 26 Nov 2020 13:29:30 -0500 From: Andrea Arcangeli To: Mike Rapoport Cc: David Hildenbrand , Vlastimil Babka , Mel Gorman , Andrew Morton , linux-mm@kvack.org, Qian Cai , Michal Hocko , linux-kernel@vger.kernel.org, Baoquan He Subject: Re: [PATCH 1/1] mm: compaction: avoid fast_isolate_around() to set pageblock_skip on reserved pages Message-ID: References: <35F8AADA-6CAA-4BD6-A4CF-6F29B3F402A4@redhat.com> <20201125210414.GO123287@linux.ibm.com> <20201126093602.GQ123287@linux.ibm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20201126093602.GQ123287@linux.ibm.com> User-Agent: Mutt/2.0.2 (2020-11-20) X-Scanned-By: MIMEDefang 2.79 on 10.5.11.15 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 Thu, Nov 26, 2020 at 11:36:02AM +0200, Mike Rapoport wrote: > memory.reserved cannot be calculated automatically. It represents all > the memory allocations made before page allocator is up. And as > memblock_reserve() is the most basic to allocate memory early at boot we > cannot really delete it ;-) Well this explanation totally covers "memory allocated early at boot" that overlaps with memblock.memory. Does the E820_TYPE_SOFT_RESERVED range added to memblock.reserve define as "memory allocated early at boot"? Does it overlap ranges added with any RAM added to memblock.memory? if (entry->type == E820_TYPE_SOFT_RESERVED) memblock_reserve(entry->addr, entry->size); if (entry->type != E820_TYPE_RAM && entry->type != E820_TYPE_RESERVED_KERN) continue; memblock_add(entry->addr, entry->size); To me the above looks it's being used for something completely different than from reserving "memory allocated early at boot". Why there is no warning at boot if there's no overlap between memblock.resereve and memblock.memory? My question about memblock.reserve is really about the non overlapping ranges: why are ranges non overlapping with memblock.memory regions, added to memblock.reserve, and why aren't those calculated automatically as reverse of memblock.memory? It's easy to see that when memblock.reserve overlaps fully, it makes perfect sense and it has to stay for it. I was really only thinking at the usage like above of memblock_reserve that looks like it should be turned into a noop and deleted. Thanks, Andrea