From: Tang Chen <tangchen@cn.fujitsu.com> To: "Rafael J. Wysocki" <rjw@sisk.pl> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>, Toshi Kani <toshi.kani@hp.com>, ACPI Devel Maling List <linux-acpi@vger.kernel.org>, LKML <linux-kernel@vger.kernel.org>, isimatu.yasuaki@jp.fujitsu.com, vasilis.liaskovitis@profitbricks.com, Len Brown <lenb@kernel.org>, linux-mm@kvack.org Subject: Re: [PATCH 2/2 v2, RFC] Driver core: Introduce offline/online callbacks for memory blocks Date: Wed, 22 May 2013 12:45:34 +0800 [thread overview] Message-ID: <519C4D6E.6080902@cn.fujitsu.com> (raw) In-Reply-To: <1824290.fKsAJTo9gA@vostro.rjw.lan> Hi Rafael, On 05/21/2013 07:15 PM, Rafael J. Wysocki wrote: ...... >>> + mem->state = to_state; >>> + if (to_state == MEM_ONLINE) >>> + mem->last_online = online_type; >> >> Why do we need to remember last online type ? >> >> And as far as I know, we can obtain which zone a page was in last time it >> was onlined by check page->flags, just like online_pages() does. If we >> use online_kernel or online_movable, the zone boundary will be >> recalculated. >> So we don't need to remember the last online type. >> >> Seeing from your patch, I guess memory_subsys_online() can only handle >> online and offline. So mem->last_online is used to remember what user has >> done through the original way to trigger memory hot-remove, right ? And >> when >> user does it in this new way, it just does the same thing as user does last >> time. >> >> But I still think we don't need to remember it because if finally you call >> online_pages(), it just does the same thing as last time by default. >> >> online_pages() >> { >> ...... >> if (online_type == ONLINE_KERNEL ...... >> >> if (online_type == ONLINE_MOVABLE...... >> >> zone = page_zone(pfn_to_page(pfn)); >> >> /* Here, the page will be put into the zone which it belong to last >> time. */ > > To be honest, it wasn't entirely clear to me that online_pages() would do the > same thing as last time by default. Suppose, for example, that the previous > online_type was ONLINE_MOVABLE. How online_pages() is supposed to know that > it should do the move_pfn_zone_right() if we don't tell it to do that? Or > is that unnecessary, because it's already been done previously? Yes, it is unnecessary. move_pfn_zone_right/left() will modify the zone related bits in page->flags. But when the page is offline, the zone related bits in page->flags will not change. So when it is online again, by dafault, it will be in the zone which it was in last time. ...... >> >> I just thought of it. Maybe I missed something in your design. Please tell >> me if I'm wrong. > > Well, so what should be passed to __memory_block_change_state() in > memory_subsys_online()? -1? If you want to keep the last time status, you can pass ONLINE_KEEP. Or -1 is all right. Thanks. :) > >> Reviewed-by: Tang Chen<tangchen@cn.fujitsu.com> >> >> Thanks. :) > > Thanks for your comments, > Rafael > > -- 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>
WARNING: multiple messages have this Message-ID (diff)
From: Tang Chen <tangchen@cn.fujitsu.com> To: "Rafael J. Wysocki" <rjw@sisk.pl> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>, Toshi Kani <toshi.kani@hp.com>, ACPI Devel Maling List <linux-acpi@vger.kernel.org>, LKML <linux-kernel@vger.kernel.org>, isimatu.yasuaki@jp.fujitsu.com, vasilis.liaskovitis@profitbricks.com, Len Brown <lenb@kernel.org>, linux-mm@kvack.org Subject: Re: [PATCH 2/2 v2, RFC] Driver core: Introduce offline/online callbacks for memory blocks Date: Wed, 22 May 2013 12:45:34 +0800 [thread overview] Message-ID: <519C4D6E.6080902@cn.fujitsu.com> (raw) In-Reply-To: <1824290.fKsAJTo9gA@vostro.rjw.lan> Hi Rafael, On 05/21/2013 07:15 PM, Rafael J. Wysocki wrote: ...... >>> + mem->state = to_state; >>> + if (to_state == MEM_ONLINE) >>> + mem->last_online = online_type; >> >> Why do we need to remember last online type ? >> >> And as far as I know, we can obtain which zone a page was in last time it >> was onlined by check page->flags, just like online_pages() does. If we >> use online_kernel or online_movable, the zone boundary will be >> recalculated. >> So we don't need to remember the last online type. >> >> Seeing from your patch, I guess memory_subsys_online() can only handle >> online and offline. So mem->last_online is used to remember what user has >> done through the original way to trigger memory hot-remove, right ? And >> when >> user does it in this new way, it just does the same thing as user does last >> time. >> >> But I still think we don't need to remember it because if finally you call >> online_pages(), it just does the same thing as last time by default. >> >> online_pages() >> { >> ...... >> if (online_type == ONLINE_KERNEL ...... >> >> if (online_type == ONLINE_MOVABLE...... >> >> zone = page_zone(pfn_to_page(pfn)); >> >> /* Here, the page will be put into the zone which it belong to last >> time. */ > > To be honest, it wasn't entirely clear to me that online_pages() would do the > same thing as last time by default. Suppose, for example, that the previous > online_type was ONLINE_MOVABLE. How online_pages() is supposed to know that > it should do the move_pfn_zone_right() if we don't tell it to do that? Or > is that unnecessary, because it's already been done previously? Yes, it is unnecessary. move_pfn_zone_right/left() will modify the zone related bits in page->flags. But when the page is offline, the zone related bits in page->flags will not change. So when it is online again, by dafault, it will be in the zone which it was in last time. ...... >> >> I just thought of it. Maybe I missed something in your design. Please tell >> me if I'm wrong. > > Well, so what should be passed to __memory_block_change_state() in > memory_subsys_online()? -1? If you want to keep the last time status, you can pass ONLINE_KEEP. Or -1 is all right. Thanks. :) > >> Reviewed-by: Tang Chen<tangchen@cn.fujitsu.com> >> >> Thanks. :) > > Thanks for your comments, > Rafael > >
next prev parent reply other threads:[~2013-05-22 4:45 UTC|newest] Thread overview: 105+ messages / expand[flat|nested] mbox.gz Atom feed top 2013-04-29 12:23 [PATCH 0/3 RFC] Driver core / ACPI: Add offline/online for graceful hot-removal of devices Rafael J. Wysocki 2013-04-29 12:26 ` [PATCH 1/3 RFC] Driver core: Add offline/online device operations Rafael J. Wysocki 2013-04-29 23:10 ` Greg Kroah-Hartman 2013-04-30 11:59 ` Rafael J. Wysocki 2013-04-30 15:32 ` Greg Kroah-Hartman 2013-04-30 20:05 ` Rafael J. Wysocki 2013-04-30 23:38 ` Toshi Kani 2013-05-02 0:58 ` Rafael J. Wysocki 2013-05-02 23:29 ` Toshi Kani 2013-05-03 11:48 ` Rafael J. Wysocki 2013-04-29 12:28 ` [PATCH 2/3 RFC] Driver core: Use generic offline/online for CPU offline/online Rafael J. Wysocki 2013-04-29 23:11 ` Greg Kroah-Hartman 2013-04-30 12:01 ` Rafael J. Wysocki 2013-04-30 15:27 ` Greg Kroah-Hartman 2013-04-30 20:06 ` Rafael J. Wysocki 2013-04-30 23:42 ` Toshi Kani 2013-05-01 14:49 ` Rafael J. Wysocki 2013-05-01 20:07 ` Toshi Kani 2013-05-02 0:26 ` Rafael J. Wysocki 2013-04-29 12:29 ` [PATCH 3/3 RFC] ACPI / hotplug: Use device offline/online for graceful hot-removal Rafael J. Wysocki 2013-04-30 23:49 ` Toshi Kani 2013-05-01 15:05 ` Rafael J. Wysocki 2013-05-01 20:20 ` Toshi Kani 2013-05-02 0:53 ` Rafael J. Wysocki 2013-05-02 12:26 ` [PATCH 0/4] Driver core / ACPI: Add offline/online for graceful hot-removal of devices Rafael J. Wysocki 2013-05-02 12:27 ` [PATCH 1/4] Driver core: Add offline/online device operations Rafael J. Wysocki 2013-05-02 13:57 ` Greg Kroah-Hartman 2013-05-02 23:11 ` Toshi Kani 2013-05-02 23:36 ` Rafael J. Wysocki 2013-05-02 23:23 ` Toshi Kani 2013-05-02 12:28 ` [PATCH 2/4] Driver core: Use generic offline/online for CPU offline/online Rafael J. Wysocki 2013-05-02 13:57 ` Greg Kroah-Hartman 2013-05-02 12:29 ` [PATCH 3/4] ACPI / hotplug: Use device offline/online for graceful hot-removal Rafael J. Wysocki 2013-05-02 12:31 ` [PATCH 4/4] ACPI / processor: Use common hotplug infrastructure Rafael J. Wysocki 2013-05-02 13:59 ` Greg Kroah-Hartman 2013-05-02 23:20 ` Toshi Kani 2013-05-03 12:05 ` Rafael J. Wysocki 2013-05-03 12:21 ` Rafael J. Wysocki 2013-05-03 18:27 ` Toshi Kani 2013-05-03 19:31 ` Rafael J. Wysocki 2013-05-03 19:34 ` Toshi Kani 2013-05-04 1:01 ` [PATCH 0/3 RFC] Driver core: Add offline/online callbacks for memory_subsys Rafael J. Wysocki 2013-05-04 1:01 ` Rafael J. Wysocki 2013-05-04 1:03 ` [PATCH 1/3 RFC] ACPI / memhotplug: Bind removable memory blocks to ACPI device nodes Rafael J. Wysocki 2013-05-04 1:03 ` Rafael J. Wysocki 2013-05-04 1:04 ` [PATCH 2/3 RFC] Driver core: Introduce types of device "online" Rafael J. Wysocki 2013-05-04 1:04 ` Rafael J. Wysocki 2013-05-04 1:06 ` [PATCH 3/3 RFC] Driver core: Introduce offline/online callbacks for memory blocks Rafael J. Wysocki 2013-05-04 1:06 ` Rafael J. Wysocki 2013-05-04 11:11 ` [PATCH 0/2 v2, RFC] Driver core: Add offline/online callbacks for memory_subsys Rafael J. Wysocki 2013-05-04 11:11 ` Rafael J. Wysocki 2013-05-04 11:12 ` [PATCH 1/2 v2, RFC] ACPI / memhotplug: Bind removable memory blocks to ACPI device nodes Rafael J. Wysocki 2013-05-04 11:12 ` Rafael J. Wysocki 2013-05-21 6:50 ` Tang Chen 2013-05-21 6:50 ` Tang Chen 2013-05-04 11:21 ` [PATCH 2/2 v2, RFC] Driver core: Introduce offline/online callbacks for memory blocks Rafael J. Wysocki 2013-05-04 11:21 ` Rafael J. Wysocki 2013-05-06 16:28 ` Vasilis Liaskovitis 2013-05-06 16:28 ` Vasilis Liaskovitis 2013-05-07 0:59 ` Rafael J. Wysocki 2013-05-07 0:59 ` Rafael J. Wysocki 2013-05-07 10:59 ` Vasilis Liaskovitis 2013-05-07 10:59 ` Vasilis Liaskovitis 2013-05-07 12:11 ` Rafael J. Wysocki 2013-05-07 12:11 ` Rafael J. Wysocki 2013-05-07 21:03 ` Toshi Kani 2013-05-07 21:03 ` Toshi Kani 2013-05-07 22:10 ` Rafael J. Wysocki 2013-05-07 22:10 ` Rafael J. Wysocki 2013-05-07 22:45 ` Toshi Kani 2013-05-07 22:45 ` Toshi Kani 2013-05-07 23:17 ` Rafael J. Wysocki 2013-05-07 23:17 ` Rafael J. Wysocki 2013-05-07 23:59 ` Toshi Kani 2013-05-07 23:59 ` Toshi Kani 2013-05-08 0:24 ` Rafael J. Wysocki 2013-05-08 0:24 ` Rafael J. Wysocki 2013-05-08 0:37 ` Toshi Kani 2013-05-08 0:37 ` Toshi Kani 2013-05-08 11:53 ` Rafael J. Wysocki 2013-05-08 11:53 ` Rafael J. Wysocki 2013-05-08 14:38 ` Toshi Kani 2013-05-08 14:38 ` Toshi Kani 2013-05-06 17:20 ` Greg Kroah-Hartman 2013-05-06 17:20 ` Greg Kroah-Hartman 2013-05-06 19:46 ` Rafael J. Wysocki 2013-05-06 19:46 ` Rafael J. Wysocki 2013-05-21 6:37 ` Tang Chen 2013-05-21 6:37 ` Tang Chen 2013-05-21 11:15 ` Rafael J. Wysocki 2013-05-21 11:15 ` Rafael J. Wysocki 2013-05-22 4:45 ` Tang Chen [this message] 2013-05-22 4:45 ` Tang Chen 2013-05-22 10:42 ` Rafael J. Wysocki 2013-05-22 10:42 ` Rafael J. Wysocki 2013-05-22 22:06 ` [PATCH] Driver core / memory: Simplify __memory_block_change_state() Rafael J. Wysocki 2013-05-22 22:06 ` Rafael J. Wysocki 2013-05-22 22:14 ` Greg Kroah-Hartman 2013-05-22 22:14 ` Greg Kroah-Hartman 2013-05-22 23:29 ` Rafael J. Wysocki 2013-05-22 23:29 ` Rafael J. Wysocki 2013-05-23 4:37 ` Tang Chen 2013-05-23 4:37 ` Tang Chen 2013-05-06 10:48 ` [PATCH 0/2 v2, RFC] Driver core: Add offline/online callbacks for memory_subsys Rafael J. Wysocki 2013-05-06 10:48 ` Rafael J. Wysocki
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=519C4D6E.6080902@cn.fujitsu.com \ --to=tangchen@cn.fujitsu.com \ --cc=gregkh@linuxfoundation.org \ --cc=isimatu.yasuaki@jp.fujitsu.com \ --cc=lenb@kernel.org \ --cc=linux-acpi@vger.kernel.org \ --cc=linux-kernel@vger.kernel.org \ --cc=linux-mm@kvack.org \ --cc=rjw@sisk.pl \ --cc=toshi.kani@hp.com \ --cc=vasilis.liaskovitis@profitbricks.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: linkBe 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.