Re: [Xen-devel] WTH is going on with memory hotplug sysf interface (was: Re: [RFC PATCH] mm, hotplug: get rid of auto_online_blocks)
On Mon, Mar 13, 2017 at 10:21:45AM +0100, Michal Hocko wrote: I agree with your general sentiment that this stuff is very nonintuitive. My criterion for nonintuitive is probably different because I would call this _completely_unusable_. Sorry for being so loud about this but the more I look into this area the more WTF code I see. This has seen close to zero review and seems to be building up more single usecase code on top of previous. We need to change this, seriously! No argument here. I'm happy to help however I can. -- Reza Arbab ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] WTH is going on with memory hotplug sysf interface (was: Re: [RFC PATCH] mm, hotplug: get rid of auto_online_blocks)
On Fri, Mar 10, 2017 at 04:53:33PM +0100, Michal Hocko wrote: OK, so while I was playing with this setup some more I probably got why this is done this way. All new memblocks are added to the zone Normal where they are accounted as spanned but not present. It's not always zone Normal. See zone_for_memory(). This leads to a workaround for having to do online_movable in descending block order. Instead of this: 1. probe block 34, probe block 33, probe block 32, ... 2. online_movable 34, online_movable 33, online_movable 32, ... you can online_movable the first block before adding the rest: 1. probe block 32, online_movable 32 2. probe block 33, probe block 34, ... - zone_for_memory() will cause these to start Movable 3. online 33, online 34, ... - they're already in Movable, so online_movable is equivalentr I agree with your general sentiment that this stuff is very nonintuitive. -- Reza Arbab ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [RFC PATCH] mm, hotplug: get rid of auto_online_blocks
On Mon, Feb 27, 2017 at 10:28:17AM +0100, Michal Hocko wrote:
diff --git a/include/linux/memory_hotplug.h b/include/linux/memory_hotplug.h
index 134a2f69c21a..a72f7f64ee26 100644
--- a/include/linux/memory_hotplug.h
+++ b/include/linux/memory_hotplug.h
@@ -100,8 +100,6 @@ extern void __online_page_free(struct page *page);
extern int try_online_node(int nid);
-extern bool memhp_auto_online;
-
#ifdef CONFIG_MEMORY_HOTREMOVE
extern bool is_pageblock_removable_nolock(struct page *page);
extern int arch_remove_memory(u64 start, u64 size);
@@ -272,7 +270,7 @@ static inline void remove_memory(int nid, u64 start, u64
size) {}
extern int walk_memory_range(unsigned long start_pfn, unsigned long end_pfn,
void *arg, int (*func)(struct memory_block *, void *));
-extern int add_memory(int nid, u64 start, u64 size);
+extern int add_memory(int nid, u64 start, u64 size, bool online);
extern int add_memory_resource(int nid, struct resource *resource, bool online);
extern int zone_for_memory(int nid, u64 start, u64 size, int zone_default,
bool for_device);
It would be nice if instead of a 'bool online' argument, add_memory()
and add_memory_resource() took an 'int online_type', ala online_pages().
That way we could specify offline, online, online+movable, etc.
--
Reza Arbab
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
