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.4 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 4815AC433E0 for ; Sun, 31 Jan 2021 08:11:30 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id E73C664E24 for ; Sun, 31 Jan 2021 08:11:29 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229638AbhAaIKU (ORCPT ); Sun, 31 Jan 2021 03:10:20 -0500 Received: from mail.kernel.org ([198.145.29.99]:57472 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229641AbhAaIEw (ORCPT ); Sun, 31 Jan 2021 03:04:52 -0500 Received: by mail.kernel.org (Postfix) with ESMTPSA id E4E1A64E24; Sun, 31 Jan 2021 08:04:00 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1612080247; bh=XnEIzyX83XCKEatOzV7kqGhG0PBgmNDeWpYG8iX3bN4=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=slnzSlsStNd+xogG8TDKRhOIRBqYOpZCmo9Edm1c99JyQJD9IuQGCoRcRoHSzBZ3M ods5OUPngMUIvypaNZ5zMLl85njgdfqs/9hK1bHqugo98fqefezPscmg8rUS+7lT2O Frp+fjFnND0oJ0+zhqZxRroHmSAY/qg3koDPzpEqWK2pPyGA8pCDc1BybvsAHzNipz eZ8DtTGIM/Oj4ZT9WvbNQz9AaJy7Wm87KYCEo39JOI9XApt3LOCAu31Ym00JMMhQNk X8+qBzp/Byz2ivLQzb2Blw9wX7DJryrBLIXDUm1Ph5K55WgJ+FfHDavkwHfNfjMzMJ L5SuXgxw2mcww== Date: Sun, 31 Jan 2021 10:03:56 +0200 From: Mike Rapoport To: Linus Torvalds Cc: Andrew Morton , Andrea Arcangeli , Baoquan He , Borislav Petkov , Chris Wilson , David Hildenbrand , "H. Peter Anvin" , Ingo Molnar , =?utf-8?Q?=C5=81ukasz?= Majczak , Mel Gorman , Michal Hocko , Mike Rapoport , Qian Cai , "Sarvela, Tomi P" , Thomas Gleixner , Vlastimil Babka , Linux Kernel Mailing List , Linux-MM , stable , the arch/x86 maintainers Subject: Re: [PATCH v4 1/2] x86/setup: always add the beginning of RAM as memblock.memory Message-ID: <20210131080356.GE242749@kernel.org> References: <20210130221035.4169-1-rppt@kernel.org> <20210130221035.4169-2-rppt@kernel.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Sat, Jan 30, 2021 at 04:37:54PM -0800, Linus Torvalds wrote: > On Sat, Jan 30, 2021 at 2:10 PM Mike Rapoport wrote: > > > > In either case, e820__memblock_setup() won't add the range 0x0000 - 0x1000 > > to memblock.memory and later during memory map initialization this range is > > left outside any zone. > > Honestly, this just sounds like memblock being stupid in the first place. > > Why aren't these zones padded to sane alignments? The implicit alignment of zones would be a guess. What alignment would be sane here? 1M? MAX_ORDER? pageblock_order? I'm not sure that if an architecture reports its memory at X and we use, say, round_down(X, 1M) for node[0]->node_start_pfn and zone[0]->zone_start_pfn it wouldn't cause boot failure on some system out there in the wild. > This patch smells like working around the memblock code being fragile > rather than a real fix. > > That's *particularly* true when the very line above it did a > "memblock_reserve()" of the exact same range that the memblock_add() > "adds". The most correct thing to do would have been to memblock_add(0, end_of_first_memory_bank); Somewhere at e820__memblock_setup(). But that would mean we also must change the way e820__memblock_setup() reserves memory and that seemed to me like really asking for troubles so I've limited the registration of memory to the range that's for sure reserved. A part of the problem is that x86 adds only usable memory to memblock.memory omitting holes and reserved areas, while free_area_init() presumes that memblock.memory covers populated physical memory. I've tried implicitly adding ranges from memblock.reserved to memblock.memory if they were not there and it had broken some arm machines: https://lore.kernel.org/lkml/127999c4-7d56-0c36-7f88-8e1a5c934cae@collabora.com I do feel that free_area_init() is fragile and no doubt there is a room for improvement there. But I think the safer way forward is to reduce inconsistencies between arch and generic code, so that we won't need to guess what is the memory layout at free_area_init() time. > Linus -- Sincerely yours, Mike.