Message ID | 20210224153950.20789-1-rppt@kernel.org (mailing list archive) |
---|---|
Headers | show
Return-Path: <SRS0=/pkq=H2=kvack.org=owner-linux-mm@kernel.org> 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=-16.8 required=3.0 tests=BAYES_00,DKIM_INVALID, DKIM_SIGNED,INCLUDES_PATCH,MAILING_LIST_MULTI,MENTIONS_GIT_HOSTING, SPF_HELO_NONE,SPF_PASS,USER_AGENT_GIT 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 14B25C433E0 for <linux-mm@archiver.kernel.org>; Wed, 24 Feb 2021 15:40:14 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 5AEA664EDB for <linux-mm@archiver.kernel.org>; Wed, 24 Feb 2021 15:40:13 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 5AEA664EDB 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 CCAA46B0005; Wed, 24 Feb 2021 10:40:12 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id C793D6B0006; Wed, 24 Feb 2021 10:40:12 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id B8E796B006C; Wed, 24 Feb 2021 10:40:12 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0179.hostedemail.com [216.40.44.179]) by kanga.kvack.org (Postfix) with ESMTP id A16126B0005 for <linux-mm@kvack.org>; Wed, 24 Feb 2021 10:40:12 -0500 (EST) Received: from smtpin30.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay02.hostedemail.com (Postfix) with ESMTP id 5B3AC9401 for <linux-mm@kvack.org>; Wed, 24 Feb 2021 15:40:12 +0000 (UTC) X-FDA: 77853572664.30.E845228 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by imf02.hostedemail.com (Postfix) with ESMTP id 837B5407F8F8 for <linux-mm@kvack.org>; Wed, 24 Feb 2021 15:39:58 +0000 (UTC) Received: by mail.kernel.org (Postfix) with ESMTPSA id 0E78064ED4; Wed, 24 Feb 2021 15:40:04 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1614181210; bh=zpbZSJ3n3/UQqrQj84VRvoG9ZEiWEcOUrHhFFU5TqVg=; h=From:To:Cc:Subject:Date:From; b=TroD82eFVaO62rdCY73XmFb46J9O6dXemfwDFKmcshbAcbvRrD9hu25kvSYRxl7bs s2JpM4JIgBZtIAY04bR5QE/x1rJgk+X11S5WvRwuUr8lowy+Ln/pJVDjSWi+jDdfVa jGPGVcs2h2kV04CoMtSB0i6x9MuWzX4SPqDIO7ET8rwZCxnfioLT+xi3DzhpJKCivl 26VVB0MnilQHpFQOqdWUotLGGaMmKPXS9iH9VeH1WQD+YLgHqv84Vf8tZF8KqreKZB wlOEd4lU5D6OQZZrJRe2cIxjgAAVj6YiGk9FO7X2u19nNNedm3GlPBEiozfImBW68t ikcoa5+909O9g== From: Mike Rapoport <rppt@kernel.org> To: Andrew Morton <akpm@linux-foundation.org> Cc: Andrea Arcangeli <aarcange@redhat.com>, Baoquan He <bhe@redhat.com>, Borislav Petkov <bp@alien8.de>, Chris Wilson <chris@chris-wilson.co.uk>, David Hildenbrand <david@redhat.com>, "H. Peter Anvin" <hpa@zytor.com>, Ingo Molnar <mingo@redhat.com>, Linus Torvalds <torvalds@linux-foundation.org>, =?utf-8?q?=C5=81ukasz_Majcz?= =?utf-8?q?ak?= <lma@semihalf.com>, Mel Gorman <mgorman@suse.de>, Michal Hocko <mhocko@kernel.org>, Mike Rapoport <rppt@kernel.org>, Mike Rapoport <rppt@linux.ibm.com>, Qian Cai <cai@lca.pw>, "Sarvela, Tomi P" <tomi.p.sarvela@intel.com>, Thomas Gleixner <tglx@linutronix.de>, Vlastimil Babka <vbabka@suse.cz>, linux-kernel@vger.kernel.org, linux-mm@kvack.org, stable@vger.kernel.org, x86@kernel.org Subject: [PATCH v7 0/1] mm: fix initialization of struct page for holes in memory layout Date: Wed, 24 Feb 2021 17:39:49 +0200 Message-Id: <20210224153950.20789-1-rppt@kernel.org> X-Mailer: git-send-email 2.28.0 MIME-Version: 1.0 X-Stat-Signature: 8618bqbgda5usge1hntahfxd8gdrw66o X-Rspamd-Server: rspam02 X-Rspamd-Queue-Id: 837B5407F8F8 Received-SPF: none (kernel.org>: No applicable sender policy available) receiver=imf02; identity=mailfrom; envelope-from="<rppt@kernel.org>"; helo=mail.kernel.org; client-ip=198.145.29.99 X-HE-DKIM-Result: pass/pass X-HE-Tag: 1614181198-108367 Content-Transfer-Encoding: quoted-printable 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: <linux-mm.kvack.org> |
Series |
mm: fix initialization of struct page for holes in memory layout
|
expand
|
From: Mike Rapoport <rppt@linux.ibm.com> Hi, @Andrew, this is based on v5.11-mmotm-2021-02-18-18-29 with the previous version reverted Commit 73a6e474cb37 ("mm: memmap_init: iterate over memblock regions rather that check each PFN") exposed several issues with the memory map initialization and these patches fix those issues. Initially there were crashes during compaction that Qian Cai reported back in April [1]. It seemed back then that the problem was fixed, but a few weeks ago Andrea Arcangeli hit the same bug [2] and there was an additional discussion at [3]. I didn't appreciate variety of ways BIOSes can report memory in the first megabyte, so previous versions of this set caused all kinds of troubles. The last version that implicitly extended node/zone to cover the complete section might also have unexpected side effects, so this time I'm trying to move in forward in baby steps. This is mostly a return to the fist version that simply merges init_unavailable_pages() into memmap_init() so that the only effective change would be more sensible zone/node links in unavailable struct pages. For now, I've dropped the patch that tried to make ZONE_DMA to span pfn 0 because it didn't cause any issues for really long time and there are way to many hidden mines around this. I have an ugly workaround for "pfn 0" issue that IMHO is the safest way to deal with it until it could be gradually fixed properly: https://git.kernel.org/pub/scm/linux/kernel/git/rppt/linux.git/commit/?h=meminit/pfn0&id=90272f37151c6e1bc2610997310c51f4e984cf2f v7: * add handling of section end that span beyond the populated zones v6: https://lore.kernel.org/lkml/20210222105728.28636-1-rppt@kernel.org * only interleave initialization of unavailable pages in memmap_init(), so that it is essentially includes init_unavailable_pages(). v5: https://lore.kernel.org/lkml/20210208110820.6269-1-rppt@kernel.org * extend node/zone spans to cover complete sections, this allows to interleave the initialization of unavailable pages with "normal" memory map init. * drop modifications to x86 early setup v4: https://lore.kernel.org/lkml/20210130221035.4169-1-rppt@kernel.org/ * make sure pages in the range 0 - start_pfn_of_lowest_zone are initialized even if an architecture hides them from the generic mm * finally make pfn 0 on x86 to be a part of memory visible to the generic mm as reserved memory. v3: https://lore.kernel.org/lkml/20210111194017.22696-1-rppt@kernel.org * use architectural zone constraints to set zone links for struct pages corresponding to the holes * drop implicit update of memblock.memory * add a patch that sets pfn 0 to E820_TYPE_RAM on x86 v2: https://lore.kernel.org/lkml/20201209214304.6812-1-rppt@kernel.org/): * added patch that adds all regions in memblock.reserved that do not overlap with memblock.memory to memblock.memory in the beginning of free_area_init() [1] https://lore.kernel.org/lkml/8C537EB7-85EE-4DCF-943E-3CC0ED0DF56D@lca.pw [2] https://lore.kernel.org/lkml/20201121194506.13464-1-aarcange@redhat.com [3] https://lore.kernel.org/mm-commits/20201206005401.qKuAVgOXr%akpm@linux-foundation.org Mike Rapoport (1): mm/page_alloc.c: refactor initialization of struct page for holes in memory layout mm/page_alloc.c | 147 +++++++++++++++++++++--------------------------- 1 file changed, 64 insertions(+), 83 deletions(-)