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 Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 59D70ECAAD3 for ; Wed, 14 Sep 2022 15:55:16 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id A5D2B8D0005; Wed, 14 Sep 2022 11:55:15 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id A0C9C8D0001; Wed, 14 Sep 2022 11:55:15 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 8D4A88D0005; Wed, 14 Sep 2022 11:55:15 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0010.hostedemail.com [216.40.44.10]) by kanga.kvack.org (Postfix) with ESMTP id 7E9648D0001 for ; Wed, 14 Sep 2022 11:55:15 -0400 (EDT) Received: from smtpin02.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay09.hostedemail.com (Postfix) with ESMTP id 57F9280BB3 for ; Wed, 14 Sep 2022 15:55:15 +0000 (UTC) X-FDA: 79911140190.02.755C204 Received: from ams.source.kernel.org (ams.source.kernel.org [145.40.68.75]) by imf08.hostedemail.com (Postfix) with ESMTP id DA61B1600A6 for ; Wed, 14 Sep 2022 15:55:13 +0000 (UTC) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ams.source.kernel.org (Postfix) with ESMTPS id 63201B818FC; Wed, 14 Sep 2022 15:55:12 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 4316CC433C1; Wed, 14 Sep 2022 15:55:10 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1663170911; bh=CeuOyMEVkb9REc9JL9C/aOeVs5Xn30KZu2M8Yy4gaf4=; h=Date:From:To:CC:Subject:In-Reply-To:References:From; b=bwd8sgNa8Eaiz7FyieMf+7bse0D/zBZQNjBrtdutXOnYa/3SeloxTdxL1OF7r8HYY UYVNGidVoxiXCrW+Myk2jalsvr65rqcRIZAwm83jl2iyigTwx4iqwveKUoNwX2RWc5 XLjSSQjrOSRZuG29AhdfbA6WBsRMR/BnQFqzTlEueFN7QQ4gh1eHUC2/3LUggDyLva IABWU8CQ5GG7Rg56pIqFIerdic5jnRPNZItEMVeaHEZ3hBQGPXb4Xb2xqYfkCQ5Nas ImH8tpWTnoINRkULP8Ot1uI8EDFRNikzIf/kIhwbF4k3ets54BPKMB05y8eGdvARZY rw9AKPBIydjzg== Date: Wed, 14 Sep 2022 16:55:04 +0100 From: Mike Rapoport To: Christophe Leroy CC: =?ISO-8859-1?Q?Pali_Roh=E1r?= , Ash Logan , "paulus@samba.org" , "mpe@ellerman.id.au" , "robh+dt@kernel.org" , "benh@kernel.crashing.org" , "linuxppc-dev@lists.ozlabs.org" , "linux-kernel@vger.kernel.org" , "j.ne@posteo.net" , "linux-mm@kvack.org" Subject: Re: Fragmented physical memory on powerpc/32 User-Agent: K-9 Mail for Android In-Reply-To: References: <20220609222420.ponpoodiqmaqtwht@pali> <20220808184034.lskqrk6z3gb5q76r@pali> <219cda7b-da4b-7a5a-9809-0878e0fc02ba@csgroup.eu> <20220908153511.57ceunyusziqfcav@pali> <20220908201701.sd3zqn5hfixmjvhh@pali> <9fbc5338-5e10-032a-8f55-e080bd93f74b@csgroup.eu> <20220912211623.djb7fckgknyfmof7@pali> <1c95875c-29f8-68b7-e480-fed8614f3037@csgroup.eu> <4f540391-37dc-8e22-be0a-74543082504d@csgroup.eu> Message-ID: <9779CA34-E40D-4035-A319-A92D2F6E4DDF@kernel.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1663170914; a=rsa-sha256; cv=none; b=tsusG7G5VPIfJTOCdmR+ezR6GheVpImaSkc9Rzs/6MUo/QoVafr4DE6RWC1o+Nbnp3Oq6V 1zS43UZT20Mk/KgEDIh5sFMAts2dvC/Ucdvm5dAvtQCd0lZRyxj9QvrgclepfJb0c5bhab Blwdw0EzDlD0iKu7DRejxUoAjQIi8G8= ARC-Authentication-Results: i=1; imf08.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=bwd8sgNa; dmarc=pass (policy=none) header.from=kernel.org; spf=pass (imf08.hostedemail.com: domain of rppt@kernel.org designates 145.40.68.75 as permitted sender) smtp.mailfrom=rppt@kernel.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1663170914; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=zdimIx2nbQWHc0kGCO0Ttw/+o6hd05EBd33/gFoEX18=; b=uODtDMcFIZLCSFVO8H7qvG9zJhVbx726kTjB3BthPcdt1WIFbbzQ8vE/3esly9iQbwEtgF lK8GivK7gpDF0jNNXgZMa5cT1ceePBxJhCS3m3A3ZcS/XmI6P7tC/1CWnZ6zQUvXTUETeY 8scSNLfcrR5ulJhyYAk1EmPYAewH5aU= Authentication-Results: imf08.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=bwd8sgNa; dmarc=pass (policy=none) header.from=kernel.org; spf=pass (imf08.hostedemail.com: domain of rppt@kernel.org designates 145.40.68.75 as permitted sender) smtp.mailfrom=rppt@kernel.org X-Rspamd-Server: rspam06 X-Rspamd-Queue-Id: DA61B1600A6 X-Stat-Signature: 568bcp1cmm4dc7cyxzeo6gheh93gois3 X-Rspam-User: X-HE-Tag: 1663170913-395439 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 September 14, 2022 10:43:52 AM GMT+01:00, Christophe Leroy wrote: > > >Le 14/09/2022 =C3=A0 11:32, Mike Rapoport a =C3=A9crit=C2=A0: >> On Tue, Sep 13, 2022 at 02:36:13PM +0200, Christophe Leroy wrote: >>> >>> >>> Le 13/09/2022 =C3=A0 08:11, Christophe Leroy a =C3=A9crit=C2=A0: >>>> >>>> >>>> Le 12/09/2022 =C3=A0 23:16, Pali Roh=C3=A1r a =C3=A9crit=C2=A0: >>>>>> >>>>>> My guess would be that something went wrong in the linear map >>>>>> setup, but it >>>>>> won't hurt running with "memblock=3Ddebug" added to the kernel >>>>>> command line >>>>>> to see if there is anything suspicious there=2E >>>>> >>>>> Here is boot log on serial console with memblock=3Ddebug command lin= e: >>>>> >>>> =2E=2E=2E >>>>> >>>>> Do you need something more for debug? >>>> >>>> Can you send me the 'vmlinux' used to generate the above Oops so that= I >>>> can see exactly where we are in function mem_init()=2E >>>> >>>> And could you also try without CONFIG_HIGHMEM just in case=2E >>>> >>> >>> I looked at the vmlinux you sent me, the problem is in the loop for hi= ghmem >>> in mem_init()=2E It crashes in the call to free_highmem_page() >>> >>> #ifdef CONFIG_HIGHMEM >>> { >>> unsigned long pfn, highmem_mapnr; >>> >>> highmem_mapnr =3D lowmem_end_addr >> PAGE_SHIFT; >>> for (pfn =3D highmem_mapnr; pfn < max_mapnr; ++pfn) { >>> phys_addr_t paddr =3D (phys_addr_t)pfn << PAGE_SHIFT; >>> struct page *page =3D pfn_to_page(pfn); >>> if (!memblock_is_reserved(paddr)) >>> free_highmem_page(page); >>> } >>> } >>> #endif /* CONFIG_HIGHMEM */ >>> >>> >>> As far as I can see in the memblock debug lines, the holes don't seem = to be >>> marked as reserved by memblock=2E So it is above valid ? Other archite= ctures >>> seem to do differently=2E >>> >>> Can you try by replacing !memblock_is_reserved(paddr) by >>> memblock_is_memory(paddr) ? >>=20 >> The holes should not be marked as reserved, we just need to loop over t= he >> memory ranges rather than over pfns=2E Then the holes will be taken int= o >> account=2E >>=20 >> I believe arm and xtensa got this right: >>=20 >> (from arch/arm/mm/init=2Ec) >>=20 >> static void __init free_highpages(void) >> { >> #ifdef CONFIG_HIGHMEM >> unsigned long max_low =3D max_low_pfn; >> phys_addr_t range_start, range_end; >> u64 i; >>=20 >> /* set highmem page free */ >> for_each_free_mem_range(i, NUMA_NO_NODE, MEMBLOCK_NONE, >> &range_start, &range_end, NULL) { >> unsigned long start =3D PFN_UP(range_start); >> unsigned long end =3D PFN_DOWN(range_end); >>=20 >> /* Ignore complete lowmem entries */ >> if (end <=3D max_low) >> continue; >>=20 >> /* Truncate partial highmem entries */ >> if (start < max_low) >> start =3D max_low; >>=20 >> for (; start < end; start++) >> free_highmem_page(pfn_to_page(start)); >> } >> #endif >> } >>=20 > > >And what about the way MIPS does it ? > >static inline void __init mem_init_free_highmem(void) >{ >#ifdef CONFIG_HIGHMEM > unsigned long tmp; > > if (cpu_has_dc_aliases) > return; > > for (tmp =3D highstart_pfn; tmp < highend_pfn; tmp++) { > struct page *page =3D pfn_to_page(tmp); > > if (!memblock_is_memory(PFN_PHYS(tmp))) > SetPageReserved(page); > else > free_highmem_page(page); > } >#endif >} This iterates over all PFNs in the highmem range and skips those in holes= =2E for_each_free_mem_range() skips the holes altogether=2E Largely, I think we need to move, say, arm's version to mm/ and use it eve= rywhere, except, perhaps, x86=2E >Christophe --=20 Sincerely yours, Mike