linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Christophe Leroy <christophe.leroy@csgroup.eu>
To: Mike Rapoport <rppt@kernel.org>
Cc: "Pali Rohár" <pali@kernel.org>, "Ash Logan" <ash@heyquark.com>,
	"paulus@samba.org" <paulus@samba.org>,
	"mpe@ellerman.id.au" <mpe@ellerman.id.au>,
	"robh+dt@kernel.org" <robh+dt@kernel.org>,
	"benh@kernel.crashing.org" <benh@kernel.crashing.org>,
	"linuxppc-dev@lists.ozlabs.org" <linuxppc-dev@lists.ozlabs.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"j.ne@posteo.net" <j.ne@posteo.net>,
	"linux-mm@kvack.org" <linux-mm@kvack.org>
Subject: Re: Fragmented physical memory on powerpc/32
Date: Wed, 14 Sep 2022 09:43:52 +0000	[thread overview]
Message-ID: <ed8ff681-4182-3f9f-a65f-21cf5012fff0@csgroup.eu> (raw)
In-Reply-To: <YyGfkDKgeW7/nNlr@kernel.org>



Le 14/09/2022 à 11:32, Mike Rapoport a écrit :
> On Tue, Sep 13, 2022 at 02:36:13PM +0200, Christophe Leroy wrote:
>>
>>
>> Le 13/09/2022 à 08:11, Christophe Leroy a écrit :
>>>
>>>
>>> Le 12/09/2022 à 23:16, Pali Rohár a écrit :
>>>>>
>>>>> My guess would be that something went wrong in the linear map
>>>>> setup, but it
>>>>> won't hurt running with "memblock=debug" added to the kernel
>>>>> command line
>>>>> to see if there is anything suspicious there.
>>>>
>>>> Here is boot log on serial console with memblock=debug command line:
>>>>
>>> ...
>>>>
>>>> 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().
>>>
>>> And could you also try without CONFIG_HIGHMEM just in case.
>>>
>>
>> I looked at the vmlinux you sent me, the problem is in the loop for highmem
>> in mem_init(). It crashes in the call to free_highmem_page()
>>
>> #ifdef CONFIG_HIGHMEM
>> 	{
>> 		unsigned long pfn, highmem_mapnr;
>>
>> 		highmem_mapnr = lowmem_end_addr >> PAGE_SHIFT;
>> 		for (pfn = highmem_mapnr; pfn < max_mapnr; ++pfn) {
>> 			phys_addr_t paddr = (phys_addr_t)pfn << PAGE_SHIFT;
>> 			struct page *page = 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. So it is above valid ? Other architectures
>> seem to do differently.
>>
>> Can you try by replacing !memblock_is_reserved(paddr) by
>> memblock_is_memory(paddr) ?
> 
> The holes should not be marked as reserved, we just need to loop over the
> memory ranges rather than over pfns. Then the holes will be taken into
> account.
> 
> I believe arm and xtensa got this right:
> 
> (from arch/arm/mm/init.c)
> 
> static void __init free_highpages(void)
> {
> #ifdef CONFIG_HIGHMEM
> 	unsigned long max_low = max_low_pfn;
> 	phys_addr_t range_start, range_end;
> 	u64 i;
> 
> 	/* set highmem page free */
> 	for_each_free_mem_range(i, NUMA_NO_NODE, MEMBLOCK_NONE,
> 				&range_start, &range_end, NULL) {
> 		unsigned long start = PFN_UP(range_start);
> 		unsigned long end = PFN_DOWN(range_end);
> 
> 		/* Ignore complete lowmem entries */
> 		if (end <= max_low)
> 			continue;
> 
> 		/* Truncate partial highmem entries */
> 		if (start < max_low)
> 			start = max_low;
> 
> 		for (; start < end; start++)
> 			free_highmem_page(pfn_to_page(start));
> 	}
> #endif
> }
> 


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 = highstart_pfn; tmp < highend_pfn; tmp++) {
		struct page *page = pfn_to_page(tmp);

		if (!memblock_is_memory(PFN_PHYS(tmp)))
			SetPageReserved(page);
		else
			free_highmem_page(page);
	}
#endif
}


Christophe

  reply	other threads:[~2022-09-14  9:43 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <20220302044406.63401-1-ash@heyquark.com>
     [not found] ` <20220302044406.63401-12-ash@heyquark.com>
     [not found]   ` <20220513224353.n56qg5fhstbaqhfz@pali>
     [not found]     ` <d84e4d24-f350-80fc-6c31-b7e7f8d429f4@heyquark.com>
     [not found]       ` <20220520080454.c3cqodsdbfbkmg56@pali>
     [not found]         ` <935b426a-6c64-beb0-907f-8c3f0a089ab7@heyquark.com>
2022-05-20 12:30           ` [PATCH 11/12] powerpc: wiiu: don't enforce flat memory Pali Rohár
2022-06-09 22:24             ` Pali Rohár
2022-08-08 18:40               ` Pali Rohár
2022-09-08 15:25                 ` Christophe Leroy
2022-09-08 15:35                   ` Pali Rohár
2022-09-08 20:17                     ` Fragmented physical memory on powerpc/32 Pali Rohár
2022-09-10  9:39                       ` Christophe Leroy
2022-09-12 14:48                         ` Mike Rapoport
2022-09-12 21:16                           ` Pali Rohár
2022-09-13  6:11                             ` Christophe Leroy
2022-09-13 12:36                               ` Christophe Leroy
2022-09-14  9:32                                 ` Mike Rapoport
2022-09-14  9:43                                   ` Christophe Leroy [this message]
2022-09-14 15:55                                     ` Mike Rapoport
2022-09-14 19:56                                       ` Pali Rohár

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=ed8ff681-4182-3f9f-a65f-21cf5012fff0@csgroup.eu \
    --to=christophe.leroy@csgroup.eu \
    --cc=ash@heyquark.com \
    --cc=benh@kernel.crashing.org \
    --cc=j.ne@posteo.net \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=linuxppc-dev@lists.ozlabs.org \
    --cc=mpe@ellerman.id.au \
    --cc=pali@kernel.org \
    --cc=paulus@samba.org \
    --cc=robh+dt@kernel.org \
    --cc=rppt@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).