From: Toshi Kani <toshi.kani@hp.com>
To: "Rafael J. Wysocki" <rjw@sisk.pl>
Cc: ACPI Devel Maling List <linux-acpi@vger.kernel.org>,
LKML <linux-kernel@vger.kernel.org>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
Wen Congyang <wency@cn.fujitsu.com>,
Tang Chen <tangchen@cn.fujitsu.com>,
Yasuaki Ishimatsu <isimatu.yasuaki@jp.fujitsu.com>,
Andrew Morton <akpm@linux-foundation.org>,
Jiang Liu <liuj97@gmail.com>,
Vasilis Liaskovitis <vasilis.liaskovitis@profitbricks.com>,
linux-mm@kvack.org
Subject: Re: [PATCH *5/5] Memory hotplug / ACPI: Simplify memory removal (was: Re: [PATCH 5/5] ACPI / memhotplug: Drop unnecessary code)
Date: Thu, 23 May 2013 10:45:33 -0600 [thread overview]
Message-ID: <1369327533.5673.75.camel@misato.fc.hp.com> (raw)
In-Reply-To: <13857057.cWE1koxP0r@vostro.rjw.lan>
On Thu, 2013-05-23 at 00:09 +0200, Rafael J. Wysocki wrote:
> On Monday, May 20, 2013 01:55:33 PM Toshi Kani wrote:
> > On Mon, 2013-05-20 at 21:47 +0200, Rafael J. Wysocki wrote:
> > > On Monday, May 20, 2013 11:27:56 AM Toshi Kani wrote:
> > > > On Sun, 2013-05-19 at 01:34 +0200, Rafael J. Wysocki wrote:
> > > > > From: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
> >
> > :
> >
> > > > > - lock_memory_hotplug();
> > > > > -
> > > > > - /*
> > > > > - * we have offlined all memory blocks like this:
> > > > > - * 1. lock memory hotplug
> > > > > - * 2. offline a memory block
> > > > > - * 3. unlock memory hotplug
> > > > > - *
> > > > > - * repeat step1-3 to offline the memory block. All memory blocks
> > > > > - * must be offlined before removing memory. But we don't hold the
> > > > > - * lock in the whole operation. So we should check whether all
> > > > > - * memory blocks are offlined.
> > > > > - */
> > > > > -
> > > > > - ret = walk_memory_range(start_pfn, end_pfn, NULL,
> > > > > - is_memblock_offlined_cb);
> > > > > - if (ret) {
> > > > > - unlock_memory_hotplug();
> > > > > - return ret;
> > > > > - }
> > > > > -
> > > >
> > > > I think the above procedure is still useful for safe guard.
> > >
> > > But then it shoud to BUG_ON() instead of returning an error (which isn't very
> > > useful for anything now).
> >
> > Right since we cannot fail at that state.
> >
> > > > > - /* remove memmap entry */
> > > > > - firmware_map_remove(start, start + size, "System RAM");
> > > > > -
> > > > > - arch_remove_memory(start, size);
> > > > > -
> > > > > - try_offline_node(nid);
> > > >
> > > > The above procedure performs memory hot-delete specific operations and
> > > > is necessary.
> > >
> > > OK, I see. I'll replace this patch with something simpler, then.
> >
> > Thanks.
>
> The replacement patch is appended.
The updated patch looks good.
Reviewed-by: Toshi Kani <toshi.kani@hp.com>
Thanks,
-Toshi
>
> Thanks,
> Rafael
>
> ---
> From: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
> Subject: Memory hotplug / ACPI: Simplify memory removal
>
> Now that the memory offlining should be taken care of by the
> companion device offlining code in acpi_scan_hot_remove(), the
> ACPI memory hotplug driver doesn't need to offline it in
> remove_memory() any more. Moreover, since the return value of
> remove_memory() is not used, it's better to make it be a void
> function and trigger a BUG() if the memory scheduled for removal is
> not offline.
>
> Change the code in accordance with the above observations.
>
> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
> ---
> drivers/acpi/acpi_memhotplug.c | 13 +------
> include/linux/memory_hotplug.h | 2 -
> mm/memory_hotplug.c | 71 ++++-------------------------------------
> 3 files changed, 12 insertions(+), 74 deletions(-)
WARNING: multiple messages have this Message-ID (diff)
From: Toshi Kani <toshi.kani@hp.com>
To: "Rafael J. Wysocki" <rjw@sisk.pl>
Cc: ACPI Devel Maling List <linux-acpi@vger.kernel.org>,
LKML <linux-kernel@vger.kernel.org>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
Wen Congyang <wency@cn.fujitsu.com>,
Tang Chen <tangchen@cn.fujitsu.com>,
Yasuaki Ishimatsu <isimatu.yasuaki@jp.fujitsu.com>,
Andrew Morton <akpm@linux-foundation.org>,
Jiang Liu <liuj97@gmail.com>,
Vasilis Liaskovitis <vasilis.liaskovitis@profitbricks.com>,
linux-mm@kvack.org
Subject: Re: [PATCH *5/5] Memory hotplug / ACPI: Simplify memory removal (was: Re: [PATCH 5/5] ACPI / memhotplug: Drop unnecessary code)
Date: Thu, 23 May 2013 10:45:33 -0600 [thread overview]
Message-ID: <1369327533.5673.75.camel@misato.fc.hp.com> (raw)
In-Reply-To: <13857057.cWE1koxP0r@vostro.rjw.lan>
On Thu, 2013-05-23 at 00:09 +0200, Rafael J. Wysocki wrote:
> On Monday, May 20, 2013 01:55:33 PM Toshi Kani wrote:
> > On Mon, 2013-05-20 at 21:47 +0200, Rafael J. Wysocki wrote:
> > > On Monday, May 20, 2013 11:27:56 AM Toshi Kani wrote:
> > > > On Sun, 2013-05-19 at 01:34 +0200, Rafael J. Wysocki wrote:
> > > > > From: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
> >
> > :
> >
> > > > > - lock_memory_hotplug();
> > > > > -
> > > > > - /*
> > > > > - * we have offlined all memory blocks like this:
> > > > > - * 1. lock memory hotplug
> > > > > - * 2. offline a memory block
> > > > > - * 3. unlock memory hotplug
> > > > > - *
> > > > > - * repeat step1-3 to offline the memory block. All memory blocks
> > > > > - * must be offlined before removing memory. But we don't hold the
> > > > > - * lock in the whole operation. So we should check whether all
> > > > > - * memory blocks are offlined.
> > > > > - */
> > > > > -
> > > > > - ret = walk_memory_range(start_pfn, end_pfn, NULL,
> > > > > - is_memblock_offlined_cb);
> > > > > - if (ret) {
> > > > > - unlock_memory_hotplug();
> > > > > - return ret;
> > > > > - }
> > > > > -
> > > >
> > > > I think the above procedure is still useful for safe guard.
> > >
> > > But then it shoud to BUG_ON() instead of returning an error (which isn't very
> > > useful for anything now).
> >
> > Right since we cannot fail at that state.
> >
> > > > > - /* remove memmap entry */
> > > > > - firmware_map_remove(start, start + size, "System RAM");
> > > > > -
> > > > > - arch_remove_memory(start, size);
> > > > > -
> > > > > - try_offline_node(nid);
> > > >
> > > > The above procedure performs memory hot-delete specific operations and
> > > > is necessary.
> > >
> > > OK, I see. I'll replace this patch with something simpler, then.
> >
> > Thanks.
>
> The replacement patch is appended.
The updated patch looks good.
Reviewed-by: Toshi Kani <toshi.kani@hp.com>
Thanks,
-Toshi
>
> Thanks,
> Rafael
>
> ---
> From: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
> Subject: Memory hotplug / ACPI: Simplify memory removal
>
> Now that the memory offlining should be taken care of by the
> companion device offlining code in acpi_scan_hot_remove(), the
> ACPI memory hotplug driver doesn't need to offline it in
> remove_memory() any more. Moreover, since the return value of
> remove_memory() is not used, it's better to make it be a void
> function and trigger a BUG() if the memory scheduled for removal is
> not offline.
>
> Change the code in accordance with the above observations.
>
> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
> ---
> drivers/acpi/acpi_memhotplug.c | 13 +------
> include/linux/memory_hotplug.h | 2 -
> mm/memory_hotplug.c | 71 ++++-------------------------------------
> 3 files changed, 12 insertions(+), 74 deletions(-)
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
next prev parent reply other threads:[~2013-05-23 16:45 UTC|newest]
Thread overview: 31+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-05-18 23:29 [PATCH 0/5] ACPI / scan / memhotplug: ACPI hotplug rework followup changes Rafael J. Wysocki
2013-05-18 23:29 ` Rafael J. Wysocki
2013-05-18 23:30 ` [PATCH 1/5] ACPI: Drop removal_type field from struct acpi_device Rafael J. Wysocki
2013-05-18 23:30 ` Rafael J. Wysocki
2013-05-18 23:31 ` [PATCH 2/5] ACPI / processor: Pass processor object handle to acpi_bind_one() Rafael J. Wysocki
2013-05-18 23:31 ` Rafael J. Wysocki
2013-05-18 23:33 ` [PATCH 3/5] Driver core / MM: Drop offline_memory_block() Rafael J. Wysocki
2013-05-18 23:33 ` Rafael J. Wysocki
2013-05-19 1:23 ` Greg Kroah-Hartman
2013-05-19 1:23 ` Greg Kroah-Hartman
2013-05-18 23:34 ` [PATCH 4/5] ACPI / scan: Add second pass of companion offlining to hot-remove code Rafael J. Wysocki
2013-05-18 23:34 ` Rafael J. Wysocki
2013-05-21 7:34 ` Xishi Qiu
2013-05-21 7:34 ` Xishi Qiu
2013-05-21 7:34 ` Xishi Qiu
2013-05-21 10:59 ` Rafael J. Wysocki
2013-05-21 10:59 ` Rafael J. Wysocki
2013-05-18 23:34 ` [PATCH 5/5] ACPI / memhotplug: Drop unnecessary code Rafael J. Wysocki
2013-05-18 23:34 ` Rafael J. Wysocki
2013-05-20 17:27 ` Toshi Kani
2013-05-20 17:27 ` Toshi Kani
2013-05-20 19:47 ` Rafael J. Wysocki
2013-05-20 19:47 ` Rafael J. Wysocki
2013-05-20 19:55 ` Toshi Kani
2013-05-20 19:55 ` Toshi Kani
2013-05-20 21:31 ` Toshi Kani
2013-05-20 21:31 ` Toshi Kani
2013-05-22 22:09 ` [PATCH *5/5] Memory hotplug / ACPI: Simplify memory removal (was: Re: [PATCH 5/5] ACPI / memhotplug: Drop unnecessary code) Rafael J. Wysocki
2013-05-22 22:09 ` Rafael J. Wysocki
2013-05-23 16:45 ` Toshi Kani [this message]
2013-05-23 16:45 ` Toshi Kani
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=1369327533.5673.75.camel@misato.fc.hp.com \
--to=toshi.kani@hp.com \
--cc=akpm@linux-foundation.org \
--cc=gregkh@linuxfoundation.org \
--cc=isimatu.yasuaki@jp.fujitsu.com \
--cc=linux-acpi@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=liuj97@gmail.com \
--cc=rjw@sisk.pl \
--cc=tangchen@cn.fujitsu.com \
--cc=vasilis.liaskovitis@profitbricks.com \
--cc=wency@cn.fujitsu.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.