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=-6.0 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS 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 52A72C433ED for ; Fri, 16 Apr 2021 11:44:39 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id B3BDC61166 for ; Fri, 16 Apr 2021 11:44:38 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org B3BDC61166 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=kernel.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 3C8DF6B0036; Fri, 16 Apr 2021 07:44:38 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 3788C6B006C; Fri, 16 Apr 2021 07:44:38 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 219686B0070; Fri, 16 Apr 2021 07:44:38 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0127.hostedemail.com [216.40.44.127]) by kanga.kvack.org (Postfix) with ESMTP id 05B6C6B0036 for ; Fri, 16 Apr 2021 07:44:37 -0400 (EDT) Received: from smtpin27.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay03.hostedemail.com (Postfix) with ESMTP id BA2D38248D51 for ; Fri, 16 Apr 2021 11:44:37 +0000 (UTC) X-FDA: 78038047794.27.12BFAE6 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by imf26.hostedemail.com (Postfix) with ESMTP id 79D0840002C3 for ; Fri, 16 Apr 2021 11:44:32 +0000 (UTC) Received: by mail.kernel.org (Postfix) with ESMTPSA id 1D13161057; Fri, 16 Apr 2021 11:44:31 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1618573476; bh=g1GQ3fMRsXXUxb3TziyhacMOOpriyOWdQMsWa6+jGug=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=BJi5NHc+XLro4v3JuXfxVimD3qTxlRIlEQW0jKcbC1fkOeMbhX+QD36Vpgv/m5ZWS w9k0pCOsSSy5e1rtpgZ6meO2kxgPq/nHRJ8xHTAE/3ueN6qs6pqlukQ1HUBO0cBT9Z 1AQShBFk27Hug5dFGtBphwLSnqUSmscREcGT3KDTwjeLt7aURG5nZp5OsnGRS8Tf1v cyIiJ5wZAAlMJuC7YOXtzgBlbuPlBe1viVwrvSNQ2ApaD5WM28tOf9xQWfW9Tzj99G Xv0t+SbyVly+TfTJMs7hkGCjxMV0CtCIjWPw5NkGbs+NBYqqEsV1nMMDioVyRJhgy+ nG5AVY/FWbnzA== Date: Fri, 16 Apr 2021 14:44:26 +0300 From: Mike Rapoport To: David Hildenbrand Cc: Ard Biesheuvel , Linux ARM , Anshuman Khandual , Catalin Marinas , Marc Zyngier , Mark Rutland , Mike Rapoport , Will Deacon , kvmarm , Linux Kernel Mailing List , Linux Memory Management List Subject: Re: [RFC/RFT PATCH 1/3] memblock: update initialization of reserved pages Message-ID: References: <20210407172607.8812-1-rppt@kernel.org> <20210407172607.8812-2-rppt@kernel.org> <0c48f98c-7454-1458-15a5-cc5a7e1fb7cd@redhat.com> <3811547a-9057-3c80-3805-2e658488ac99@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspamd-Server: rspam05 X-Rspamd-Queue-Id: 79D0840002C3 X-Stat-Signature: mxyy7pksgpw3inwu1h7f37guft54pw11 Received-SPF: none (kernel.org>: No applicable sender policy available) receiver=imf26; identity=mailfrom; envelope-from=""; helo=mail.kernel.org; client-ip=198.145.29.99 X-HE-DKIM-Result: pass/pass X-HE-Tag: 1618573472-250402 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, Apr 15, 2021 at 11:30:12AM +0200, David Hildenbrand wrote: > > Not sure we really need a new pagetype here, PG_Reserved seems to be quite > > enough to say "don't touch this". I generally agree that we could make > > PG_Reserved a PageType and then have several sub-types for reserved memory. > > This definitely will add clarity but I'm not sure that this justifies > > amount of churn and effort required to audit uses of PageResrved(). > > > Then, we could mostly avoid having to query memblock at runtime to figure > > > out that this is special memory. This would obviously be an extension to > > > this series. Just a thought. > > > > Stop pushing memblock out of kernel! ;-) > > Can't stop. Won't stop. :D > > It's lovely for booting up a kernel until we have other data-structures in > place ;) A bit more seriously, we don't have any data structure that reliably represents physical memory layout and arch-independent fashion. memblock is probably the best starting point for eventually having one. -- Sincerely yours, Mike.