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 3BDCCC433E0 for ; Sun, 31 Jan 2021 08:04:11 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id AAC9864E04 for ; Sun, 31 Jan 2021 08:04:10 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org AAC9864E04 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 0BCA26B0005; Sun, 31 Jan 2021 03:04:10 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 046546B0006; Sun, 31 Jan 2021 03:04:09 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id E29A36B006C; Sun, 31 Jan 2021 03:04:09 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0162.hostedemail.com [216.40.44.162]) by kanga.kvack.org (Postfix) with ESMTP id C9E986B0005 for ; Sun, 31 Jan 2021 03:04:09 -0500 (EST) Received: from smtpin12.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay05.hostedemail.com (Postfix) with ESMTP id 852F5181AEF1F for ; Sun, 31 Jan 2021 08:04:09 +0000 (UTC) X-FDA: 77765332218.12.worm35_3713a24275b8 Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin12.hostedemail.com (Postfix) with ESMTP id 651BF18007074 for ; Sun, 31 Jan 2021 08:04:09 +0000 (UTC) X-HE-Tag: worm35_3713a24275b8 X-Filterd-Recvd-Size: 4462 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by imf45.hostedemail.com (Postfix) with ESMTP for ; Sun, 31 Jan 2021 08:04:08 +0000 (UTC) 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: 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 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.