All of lore.kernel.org
 help / color / mirror / Atom feed
From: Nathan Fontenot <nfont@linux.vnet.ibm.com>
To: linuxppc-dev@lists.ozlabs.org
Subject: Re: [PATCH] powerpc/mm: update arch_{add,remove}_memory() for radix
Date: Thu, 23 Jun 2016 12:27:18 -0500	[thread overview]
Message-ID: <576C1BF6.3010803@linux.vnet.ibm.com> (raw)
In-Reply-To: <87mvmbygdb.fsf@skywalker.in.ibm.com>

On 06/23/2016 12:17 PM, Aneesh Kumar K.V wrote:
> Reza Arbab <arbab@linux.vnet.ibm.com> writes:
> 
>> These functions are making direct calls to the hash table APIs,
>> leading to a BUG() on systems using radix.
>>
>> Switch them to the vmemmap_{create,remove}_mapping() wrappers, and
>> move to the __meminit section.
> 
> 
> They are really not the same. They can possibly end up using different
> base page size. Also vmemmap is available only with SPARSEMEM_VMEMMAP
> enabled. Does hotplug depend on sparsemem vmemmap ?

Sparse vmemmap is supported, and I think enabled by default for pseries,
but hotplug does not depend on sparse vmemmep.

-Nathan

> 
>>
>> Signed-off-by: Reza Arbab <arbab@linux.vnet.ibm.com>
>> ---
>>  arch/powerpc/mm/mem.c | 8 ++++----
>>  1 file changed, 4 insertions(+), 4 deletions(-)
>>
>> diff --git a/arch/powerpc/mm/mem.c b/arch/powerpc/mm/mem.c
>> index 2fd57fa..80c6ee7 100644
>> --- a/arch/powerpc/mm/mem.c
>> +++ b/arch/powerpc/mm/mem.c
>> @@ -116,7 +116,7 @@ int memory_add_physaddr_to_nid(u64 start)
>>  }
>>  #endif
>>
>> -int arch_add_memory(int nid, u64 start, u64 size, bool for_device)
>> +int __meminit arch_add_memory(int nid, u64 start, u64 size, bool for_device)
>>  {
>>  	struct pglist_data *pgdata;
>>  	struct zone *zone;
>> @@ -127,7 +127,7 @@ int arch_add_memory(int nid, u64 start, u64 size, bool for_device)
>>  	pgdata = NODE_DATA(nid);
>>
>>  	start = (unsigned long)__va(start);
>> -	rc = create_section_mapping(start, start + size);
>> +	rc = vmemmap_create_mapping(start, size, __pa(start));
>>  	if (rc) {
>>  		pr_warning(
>>  			"Unable to create mapping for hot added memory 0x%llx..0x%llx: %d\n",
>> @@ -143,7 +143,7 @@ int arch_add_memory(int nid, u64 start, u64 size, bool for_device)
>>  }
>>
>>  #ifdef CONFIG_MEMORY_HOTREMOVE
>> -int arch_remove_memory(u64 start, u64 size)
>> +int __meminit arch_remove_memory(u64 start, u64 size)
>>  {
>>  	unsigned long start_pfn = start >> PAGE_SHIFT;
>>  	unsigned long nr_pages = size >> PAGE_SHIFT;
>> @@ -157,7 +157,7 @@ int arch_remove_memory(u64 start, u64 size)
>>
>>  	/* Remove htab bolted mappings for this section of memory */
>>  	start = (unsigned long)__va(start);
>> -	ret = remove_section_mapping(start, start + size);
>> +	vmemmap_remove_mapping(start, size);
>>
>>  	/* Ensure all vmalloc mappings are flushed in case they also
>>  	 * hit that section of memory
>> -- 
>> 1.8.3.1
> 
> We really want to look at memory hotplug to fully understand the
> radix impact. The unplug operation needs to do some additional freeing.
> 
> I did put in comments around that with the idea of coming back to that
> later
> 
> #ifdef CONFIG_MEMORY_HOTPLUG
> void radix__vmemmap_remove_mapping(unsigned long start, unsigned long page_size)
> {
> 	/* FIXME!! intel does more. We should free page tables mapping vmemmap ? */
> }
> #endif
> 
> -aneesh
> 
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/linuxppc-dev
> 

  reply	other threads:[~2016-06-23 17:27 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-06-23 16:39 [PATCH] powerpc/mm: update arch_{add,remove}_memory() for radix Reza Arbab
2016-06-23 17:17 ` Aneesh Kumar K.V
2016-06-23 17:27   ` Nathan Fontenot [this message]
2016-06-23 19:37   ` Reza Arbab
2016-06-23 19:52     ` Reza Arbab
2016-06-28 11:21     ` Michael Ellerman
2016-06-28 14:03       ` Aneesh Kumar K.V
2016-06-29 15:37       ` Reza Arbab
2016-06-24  3:22   ` Balbir Singh

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=576C1BF6.3010803@linux.vnet.ibm.com \
    --to=nfont@linux.vnet.ibm.com \
    --cc=linuxppc-dev@lists.ozlabs.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.