linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: Mike Rapoport <rppt@kernel.org>
To: Kefeng Wang <wangkefeng.wang@huawei.com>
Cc: David Hildenbrand <david@redhat.com>,
	linux-arm-kernel@lists.infradead.org,
	Andrew Morton <akpm@linux-foundation.org>,
	Anshuman Khandual <anshuman.khandual@arm.com>,
	Ard Biesheuvel <ardb@kernel.org>,
	Catalin Marinas <catalin.marinas@arm.com>,
	Marc Zyngier <maz@kernel.org>,
	Mark Rutland <mark.rutland@arm.com>,
	Mike Rapoport <rppt@linux.ibm.com>, Will Deacon <will@kernel.org>,
	kvmarm@lists.cs.columbia.edu, linux-kernel@vger.kernel.org,
	linux-mm@kvack.org
Subject: Re: arm32: panic in move_freepages (Was [PATCH v2 0/4] arm64: drop pfn_valid_within() and simplify pfn_valid())
Date: Tue, 11 May 2021 11:48:00 +0300	[thread overview]
Message-ID: <YJpEwF2cGjS5mKma@kernel.org> (raw)
In-Reply-To: <b91cd653-842b-0e77-5c00-17a0ac9c4b50@huawei.com>

On Mon, May 10, 2021 at 11:10:20AM +0800, Kefeng Wang wrote:
>
> > > The memory is not continuous, see MEMBLOCK:
> > >   memory size = 0x4c0fffff reserved size = 0x027ef058
> > >   memory.cnt  = 0xa
> > >   memory[0x0]    [0x80a00000-0x855fffff], 0x04c00000 bytes flags: 0x0
> > >   memory[0x1]    [0x86a00000-0x87dfffff], 0x01400000 bytes flags: 0x0
> > >   memory[0x2]    [0x8bd00000-0x8c4fffff], 0x00800000 bytes flags: 0x0
> > >   memory[0x3]    [0x8e300000-0x8ecfffff], 0x00a00000 bytes flags: 0x0
> > >   memory[0x4]    [0x90d00000-0xbfffffff], 0x2f300000 bytes flags: 0x0
> > >   memory[0x5]    [0xcc000000-0xdc9fffff], 0x10a00000 bytes flags: 0x0
> > >   memory[0x6]    [0xde700000-0xde9fffff], 0x00300000 bytes flags: 0x0
> > > ...
> > > 
> > > The pfn_range [0xde600,0xde700] => addr_range [0xde600000,0xde700000]
> > > is not available memory, and we won't create memmap , so with or without
> > > your patch, we can't see the range in free_memmap(), right?
> > 
> > This is not available memory and we won't see the reange in free_memmap(),
> > but we still should create memmap for it and that's what my patch tried to
> > do.
> > 
> > There are a lot of places in core mm that operate on pageblocks and
> > free_unused_memmap() should make sure that any pageblock has a valid memory
> > map.
> > 
> > Currently, that's not the case when SPARSEMEM=y and my patch tried to fix
> > it.
> > 
> > Can you please send log with my patch applied and with the printing of
> > ranges that are freed in free_unused_memmap() you've used in previous
> > mails?

> with your patch[1] and debug print in free_memmap,
> ----> free_memmap, start_pfn = 85800,  85800000 end_pfn = 86800, 86800000
> ----> free_memmap, start_pfn = 8c800,  8c800000 end_pfn = 8e000, 8e000000
> ----> free_memmap, start_pfn = 8f000,  8f000000 end_pfn = 90000, 90000000
> ----> free_memmap, start_pfn = dcc00,  dcc00000 end_pfn = de400, de400000
> ----> free_memmap, start_pfn = dec00,  dec00000 end_pfn = e0000, e0000000
> ----> free_memmap, start_pfn = e0c00,  e0c00000 end_pfn = e4000, e4000000
> ----> free_memmap, start_pfn = f7000,  f7000000 end_pfn = f8000, f8000000

It seems that freeing of the memory map is suboptimal still because that
code was not designed for memory layout that has more holes than Swiss
cheese. 

Still, the range [0xde600,0xde700] is not freed and there should be struct
pages for this range.

Can you add 

	dump_page(pfn_to_page(0xde600), "");

say, in the end of memblock_free_all()?
 
-- 
Sincerely yours,
Mike.

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

  reply	other threads:[~2021-05-11 12:23 UTC|newest]

Thread overview: 47+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-04-21  6:51 [PATCH v2 0/4] arm64: drop pfn_valid_within() and simplify pfn_valid() Mike Rapoport
2021-04-21  6:51 ` [PATCH v2 1/4] include/linux/mmzone.h: add documentation for pfn_valid() Mike Rapoport
2021-04-21 10:49   ` Anshuman Khandual
2021-04-21  6:51 ` [PATCH v2 2/4] memblock: update initialization of reserved pages Mike Rapoport
2021-04-21  7:49   ` David Hildenbrand
2021-04-21 10:51   ` Anshuman Khandual
2021-04-21  6:51 ` [PATCH v2 3/4] arm64: decouple check whether pfn is in linear map from pfn_valid() Mike Rapoport
2021-04-21 10:59   ` Anshuman Khandual
2021-04-21 12:19     ` Mike Rapoport
2021-04-21 13:13       ` Anshuman Khandual
2021-04-21  6:51 ` [PATCH v2 4/4] arm64: drop pfn_valid_within() and simplify pfn_valid() Mike Rapoport
2021-04-21  7:49   ` David Hildenbrand
2021-04-21 11:06   ` Anshuman Khandual
2021-04-21 12:24     ` Mike Rapoport
2021-04-21 13:15       ` Anshuman Khandual
2021-04-22  7:00 ` [PATCH v2 0/4] " Kefeng Wang
2021-04-22  7:29   ` Mike Rapoport
2021-04-22 15:28     ` Kefeng Wang
2021-04-23  8:11       ` Kefeng Wang
2021-04-25  7:19         ` arm32: panic in move_freepages (Was [PATCH v2 0/4] arm64: drop pfn_valid_within() and simplify pfn_valid()) Mike Rapoport
     [not found]           ` <52f7d03b-7219-46bc-c62d-b976bc31ebd5@huawei.com>
2021-04-26  5:20             ` Mike Rapoport
2021-04-26 15:26               ` Kefeng Wang
2021-04-27  6:23                 ` Mike Rapoport
2021-04-27 11:08                   ` Kefeng Wang
2021-04-28  5:59                     ` Mike Rapoport
2021-04-29  0:48                       ` Kefeng Wang
2021-04-29  6:57                         ` Mike Rapoport
2021-04-29 10:22                           ` Kefeng Wang
2021-04-30  9:51                             ` Mike Rapoport
2021-04-30 11:24                               ` Kefeng Wang
2021-05-03  6:26                                 ` Mike Rapoport
2021-05-03  8:07                                   ` David Hildenbrand
2021-05-03  8:44                                     ` Mike Rapoport
2021-05-06 12:47                                       ` Kefeng Wang
2021-05-07  7:17                                         ` Kefeng Wang
2021-05-07 10:30                                           ` Mike Rapoport
2021-05-07 12:34                                             ` Kefeng Wang
2021-05-09  5:59                                               ` Mike Rapoport
2021-05-10  3:10                                                 ` Kefeng Wang
2021-05-11  8:48                                                   ` Mike Rapoport [this message]
2021-05-12  3:08                                                     ` Kefeng Wang
2021-05-12  8:26                                                       ` Mike Rapoport
2021-05-13  3:44                                                         ` Kefeng Wang
2021-05-13 10:55                                                           ` Mike Rapoport
2021-05-14  2:18                                                             ` Kefeng Wang
2021-05-12  3:50             ` Matthew Wilcox
2021-04-25  6:59       ` [PATCH v2 0/4] arm64: drop pfn_valid_within() and simplify pfn_valid() Mike Rapoport

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=YJpEwF2cGjS5mKma@kernel.org \
    --to=rppt@kernel.org \
    --cc=akpm@linux-foundation.org \
    --cc=anshuman.khandual@arm.com \
    --cc=ardb@kernel.org \
    --cc=catalin.marinas@arm.com \
    --cc=david@redhat.com \
    --cc=kvmarm@lists.cs.columbia.edu \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=mark.rutland@arm.com \
    --cc=maz@kernel.org \
    --cc=rppt@linux.ibm.com \
    --cc=wangkefeng.wang@huawei.com \
    --cc=will@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).