Linux-mm Archive on lore.kernel.org
 help / color / Atom feed
From: Wei Yang <richard.weiyang@gmail.com>
To: "Raslan, KarimAllah" <karahmed@amazon.de>
Cc: "richard.weiyang@gmail.com" <richard.weiyang@gmail.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"bhe@redhat.com" <bhe@redhat.com>,
	"linux-mm@kvack.org" <linux-mm@kvack.org>,
	"cai@lca.pw" <cai@lca.pw>,
	"logang@deltatee.com" <logang@deltatee.com>,
	"akpm@linux-foundation.org" <akpm@linux-foundation.org>,
	"osalvador@suse.de" <osalvador@suse.de>,
	"rppt@linux.ibm.com" <rppt@linux.ibm.com>,
	"mhocko@suse.com" <mhocko@suse.com>,
	"pasha.tatashin@oracle.com" <pasha.tatashin@oracle.com>
Subject: Re: [PATCH] mm: sparse: Skip no-map regions in memblocks_present
Date: Sat, 13 Jul 2019 16:52:19 +0000
Message-ID: <20190713165219.n3ro7peyyml6swrk@master> (raw)
In-Reply-To: <1563026005.19043.12.camel@amazon.de>

On Sat, Jul 13, 2019 at 01:53:25PM +0000, Raslan, KarimAllah wrote:
>On Fri, 2019-07-12 at 23:09 +0000, Wei Yang wrote:
>> On Fri, Jul 12, 2019 at 10:51:31AM +0200, KarimAllah Ahmed wrote:
>> > 
>> > Do not mark regions that are marked with nomap to be present, otherwise
>> > these memblock cause unnecessarily allocation of metadata.
>> > 
>> > Cc: Andrew Morton <akpm@linux-foundation.org>
>> > Cc: Pavel Tatashin <pasha.tatashin@oracle.com>
>> > Cc: Oscar Salvador <osalvador@suse.de>
>> > Cc: Michal Hocko <mhocko@suse.com>
>> > Cc: Mike Rapoport <rppt@linux.ibm.com>
>> > Cc: Baoquan He <bhe@redhat.com>
>> > Cc: Qian Cai <cai@lca.pw>
>> > Cc: Wei Yang <richard.weiyang@gmail.com>
>> > Cc: Logan Gunthorpe <logang@deltatee.com>
>> > Cc: linux-mm@kvack.org
>> > Cc: linux-kernel@vger.kernel.org
>> > Signed-off-by: KarimAllah Ahmed <karahmed@amazon.de>
>> > ---
>> > mm/sparse.c | 4 ++++
>> > 1 file changed, 4 insertions(+)
>> > 
>> > diff --git a/mm/sparse.c b/mm/sparse.c
>> > index fd13166..33810b6 100644
>> > --- a/mm/sparse.c
>> > +++ b/mm/sparse.c
>> > @@ -256,6 +256,10 @@ void __init memblocks_present(void)
>> > 	struct memblock_region *reg;
>> > 
>> > 	for_each_memblock(memory, reg) {
>> > +
>> > +		if (memblock_is_nomap(reg))
>> > +			continue;
>> > +
>> > 		memory_present(memblock_get_region_node(reg),
>> > 			       memblock_region_memory_base_pfn(reg),
>> > 			       memblock_region_memory_end_pfn(reg));
>> 
>> 
>> The logic looks good, while I am not sure this would take effect. Since the
>> metadata is SECTION size aligned while memblock is not.
>> 
>> If I am correct, on arm64, we mark nomap memblock in map_mem()
>> 
>>     memblock_mark_nomap(kernel_start, kernel_end - kernel_start);
>
>The nomap is also done by EFI code in ${src}/drivers/firmware/efi/arm-init.c
>
>.. and hopefully in the future by this:
>https://lkml.org/lkml/2019/7/12/126
>
>So it is not really striclty associated with the map_mem().
>
>So it is extremely dependent on the platform how much memory will end up mapped??
>as nomap.
>
>> 
>> And kernel text area is less than 40M, if I am right. This means
>> memblocks_present would still mark the section present. 
>> 
>> Would you mind showing how much memory range it is marked nomap?
>
>We actually have some downstream patches that are using this nomap flag for
>more than the use-cases I described above which would enflate the nomap regions??
>a bit :)
>

Thanks for your explanation.

If my understanding is correct, the range you mark nomap could not be used by
the system, it looks those ranges are useless for the system. Just curious
about how linux could use these memory after marking nomap?

>> 
>> > 
>> > -- 
>> > 2.7.4
>> 
>
>
>
>Amazon Development Center Germany GmbH
>Krausenstr. 38
>10117 Berlin
>Geschaeftsfuehrung: Christian Schlaeger, Ralf Herbrich
>Eingetragen am Amtsgericht Charlottenburg unter HRB 149173 B
>Sitz: Berlin
>Ust-ID: DE 289 237 879
>
>

-- 
Wei Yang
Help you, Help me


      reply index

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-07-12  8:51 KarimAllah Ahmed
2019-07-12 23:09 ` Wei Yang
2019-07-13 13:53   ` Raslan, KarimAllah
2019-07-13 16:52     ` Wei Yang [this message]

Reply instructions:

You may reply publically 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=20190713165219.n3ro7peyyml6swrk@master \
    --to=richard.weiyang@gmail.com \
    --cc=akpm@linux-foundation.org \
    --cc=bhe@redhat.com \
    --cc=cai@lca.pw \
    --cc=karahmed@amazon.de \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=logang@deltatee.com \
    --cc=mhocko@suse.com \
    --cc=osalvador@suse.de \
    --cc=pasha.tatashin@oracle.com \
    --cc=rppt@linux.ibm.com \
    /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

Linux-mm Archive on lore.kernel.org

Archives are clonable:
	git clone --mirror https://lore.kernel.org/linux-mm/0 linux-mm/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 linux-mm linux-mm/ https://lore.kernel.org/linux-mm \
		linux-mm@kvack.org linux-mm@archiver.kernel.org
	public-inbox-index linux-mm


Newsgroup available over NNTP:
	nntp://nntp.lore.kernel.org/org.kvack.linux-mm


AGPL code for this site: git clone https://public-inbox.org/ public-inbox