All of lore.kernel.org
 help / color / mirror / Atom feed
From: Anshuman Khandual <anshuman.khandual@arm.com>
To: David Hildenbrand <david@redhat.com>,
	linux-kernel@vger.kernel.org,
	linux-arm-kernel@lists.infradead.org, linux-mm@kvack.org,
	akpm@linux-foundation.org, will.deacon@arm.com,
	catalin.marinas@arm.com
Cc: mhocko@suse.com, mgorman@techsingularity.net,
	james.morse@arm.com, mark.rutland@arm.com, robin.murphy@arm.com,
	cpandya@codeaurora.org, arunks@codeaurora.org,
	dan.j.williams@intel.com, osalvador@suse.de, cai@lca.pw,
	logang@deltatee.com, ira.weiny@intel.com
Subject: Re: [PATCH V2 2/2] arm64/mm: Enable memory hot remove
Date: Tue, 16 Apr 2019 15:22:28 +0530	[thread overview]
Message-ID: <eeff6d30-f6c9-733b-5a27-76d2a80c649d@arm.com> (raw)
In-Reply-To: <614fe7d2-cc5d-61a2-6894-026e30498269@redhat.com>



On 04/15/2019 07:25 PM, David Hildenbrand wrote:
>> +
>> +#ifdef CONFIG_MEMORY_HOTREMOVE
>> +int arch_remove_memory(int nid, u64 start, u64 size, struct vmem_altmap *altmap)
>> +{
>> +	unsigned long start_pfn = start >> PAGE_SHIFT;
>> +	unsigned long nr_pages = size >> PAGE_SHIFT;
>> +	struct zone *zone = page_zone(pfn_to_page(start_pfn));
>> +	int ret;
>> +
>> +	ret = __remove_pages(zone, start_pfn, nr_pages, altmap);
>> +	if (!ret)
> Please note that I posted patches that remove all error handling
> from arch_remove_memory and __remove_pages(). They are already in next/master
> 
> So this gets a lot simpler and more predictable.
> 
> 
> Author: David Hildenbrand <david@redhat.com>
> Date:   Wed Apr 10 11:02:27 2019 +1000
> 
>     mm/memory_hotplug: make __remove_pages() and arch_remove_memory() never fail
>     
>     All callers of arch_remove_memory() ignore errors.  And we should really
>     try to remove any errors from the memory removal path.  No more errors are
>     reported from __remove_pages().  BUG() in s390x code in case
>     arch_remove_memory() is triggered.  We may implement that properly later.
>     WARN in case powerpc code failed to remove the section mapping, which is
>     better than ignoring the error completely right now

Sure will follow suit next time around.

WARNING: multiple messages have this Message-ID (diff)
From: Anshuman Khandual <anshuman.khandual@arm.com>
To: David Hildenbrand <david@redhat.com>,
	linux-kernel@vger.kernel.org,
	linux-arm-kernel@lists.infradead.org, linux-mm@kvack.org,
	akpm@linux-foundation.org, will.deacon@arm.com,
	catalin.marinas@arm.com
Cc: mark.rutland@arm.com, mhocko@suse.com, ira.weiny@intel.com,
	robin.murphy@arm.com, cai@lca.pw, logang@deltatee.com,
	james.morse@arm.com, cpandya@codeaurora.org,
	arunks@codeaurora.org, dan.j.williams@intel.com,
	mgorman@techsingularity.net, osalvador@suse.de
Subject: Re: [PATCH V2 2/2] arm64/mm: Enable memory hot remove
Date: Tue, 16 Apr 2019 15:22:28 +0530	[thread overview]
Message-ID: <eeff6d30-f6c9-733b-5a27-76d2a80c649d@arm.com> (raw)
In-Reply-To: <614fe7d2-cc5d-61a2-6894-026e30498269@redhat.com>



On 04/15/2019 07:25 PM, David Hildenbrand wrote:
>> +
>> +#ifdef CONFIG_MEMORY_HOTREMOVE
>> +int arch_remove_memory(int nid, u64 start, u64 size, struct vmem_altmap *altmap)
>> +{
>> +	unsigned long start_pfn = start >> PAGE_SHIFT;
>> +	unsigned long nr_pages = size >> PAGE_SHIFT;
>> +	struct zone *zone = page_zone(pfn_to_page(start_pfn));
>> +	int ret;
>> +
>> +	ret = __remove_pages(zone, start_pfn, nr_pages, altmap);
>> +	if (!ret)
> Please note that I posted patches that remove all error handling
> from arch_remove_memory and __remove_pages(). They are already in next/master
> 
> So this gets a lot simpler and more predictable.
> 
> 
> Author: David Hildenbrand <david@redhat.com>
> Date:   Wed Apr 10 11:02:27 2019 +1000
> 
>     mm/memory_hotplug: make __remove_pages() and arch_remove_memory() never fail
>     
>     All callers of arch_remove_memory() ignore errors.  And we should really
>     try to remove any errors from the memory removal path.  No more errors are
>     reported from __remove_pages().  BUG() in s390x code in case
>     arch_remove_memory() is triggered.  We may implement that properly later.
>     WARN in case powerpc code failed to remove the section mapping, which is
>     better than ignoring the error completely right now

Sure will follow suit next time around.

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

  reply	other threads:[~2019-04-16  9:52 UTC|newest]

Thread overview: 48+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-04-14  5:59 [PATCH V2 0/2] arm64/mm: Enable memory hot remove Anshuman Khandual
2019-04-14  5:59 ` Anshuman Khandual
2019-04-14  5:59 ` [PATCH V2 1/2] mm/hotplug: Reorder arch_remove_memory() call in __remove_memory() Anshuman Khandual
2019-04-14  5:59   ` Anshuman Khandual
2019-04-15 13:58   ` David Hildenbrand
2019-04-15 13:58     ` David Hildenbrand
2019-04-16 10:12     ` Anshuman Khandual
2019-04-16 10:12       ` Anshuman Khandual
2019-04-14  5:59 ` [PATCH V2 2/2] arm64/mm: Enable memory hot remove Anshuman Khandual
2019-04-14  5:59   ` Anshuman Khandual
2019-04-15 13:48   ` Mark Rutland
2019-04-15 13:48     ` Mark Rutland
2019-04-17  9:58     ` Anshuman Khandual
2019-04-17  9:58       ` Anshuman Khandual
2019-04-17 14:21       ` Mark Rutland
2019-04-17 14:21         ` Mark Rutland
2019-04-17 16:45         ` Anshuman Khandual
2019-04-17 16:45           ` Anshuman Khandual
2019-04-17 17:39           ` Mark Rutland
2019-04-17 17:39             ` Mark Rutland
2019-04-18  5:28             ` Anshuman Khandual
2019-04-18  5:28               ` Anshuman Khandual
2019-04-23  7:31               ` Anshuman Khandual
2019-04-23  7:31                 ` Anshuman Khandual
2019-04-23  7:37                 ` David Hildenbrand
2019-04-23  7:37                   ` David Hildenbrand
2019-04-23  7:45                   ` Anshuman Khandual
2019-04-23  7:45                     ` Anshuman Khandual
2019-04-23  7:51                     ` David Hildenbrand
2019-04-23  7:51                       ` David Hildenbrand
2019-04-23  8:37                       ` Anshuman Khandual
2019-04-23  8:37                         ` Anshuman Khandual
2019-04-23 16:05                 ` Mark Rutland
2019-04-23 16:05                   ` Mark Rutland
2019-04-24  5:59                   ` Anshuman Khandual
2019-04-24  5:59                     ` Anshuman Khandual
2019-04-24  8:19                     ` Mark Rutland
2019-04-24  8:19                       ` Mark Rutland
2019-04-15 13:55   ` David Hildenbrand
2019-04-15 13:55     ` David Hildenbrand
2019-04-16  9:52     ` Anshuman Khandual [this message]
2019-04-16  9:52       ` Anshuman Khandual
2019-05-13  8:22 ` [PATCH V2 0/2] " David Hildenbrand
2019-05-13  8:22   ` David Hildenbrand
2019-05-13  8:37   ` Anshuman Khandual
2019-05-13  8:37     ` Anshuman Khandual
2019-05-13 10:01     ` David Hildenbrand
2019-05-13 10:01       ` David Hildenbrand

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=eeff6d30-f6c9-733b-5a27-76d2a80c649d@arm.com \
    --to=anshuman.khandual@arm.com \
    --cc=akpm@linux-foundation.org \
    --cc=arunks@codeaurora.org \
    --cc=cai@lca.pw \
    --cc=catalin.marinas@arm.com \
    --cc=cpandya@codeaurora.org \
    --cc=dan.j.williams@intel.com \
    --cc=david@redhat.com \
    --cc=ira.weiny@intel.com \
    --cc=james.morse@arm.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=logang@deltatee.com \
    --cc=mark.rutland@arm.com \
    --cc=mgorman@techsingularity.net \
    --cc=mhocko@suse.com \
    --cc=osalvador@suse.de \
    --cc=robin.murphy@arm.com \
    --cc=will.deacon@arm.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
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.