On 23/02/17 14:56, Nicholas Piggin wrote:
+ +static bool memtrace_offline_pages(u32 nid, u64 start_pfn, u64 nr_pages) +{ + u64 end_pfn = start_pfn + nr_pages - 1; + + if (walk_memory_range(start_pfn, end_pfn, NULL, + check_memblock_online)) + return false; + + walk_memory_range(start_pfn, end_pfn, (void *)MEM_GOING_OFFLINE, + change_memblock_state); + + if (offline_pages(start_pfn, nr_pages)) { + walk_memory_range(start_pfn, end_pfn, (void *)MEM_ONLINE, + change_memblock_state); + return false; + } + + walk_memory_range(start_pfn, end_pfn, (void *)MEM_OFFLINE, + change_memblock_state); + + /* RCU grace period? */ + flush_memory_region((u64)__va(start_pfn << PAGE_SHIFT), nr_pages << PAGE_SHIFT); + + remove_memory(nid, start_pfn << PAGE_SHIFT, nr_pages << PAGE_SHIFT); + + return true; +}This is the tricky part. Memory hotplug APIs don't seem well suited for what we're trying to do... Anyway, do a bit of grepping around for definitions of some of these calls, and how other code uses them. For example, remove_memory comment says caller must hold lock_device_hotplug() first, so we're missing that at least. I think that's also needed over the memblock state changes. We don't need an RCU grace period there AFAICT, because offline_pages should have us covered. I haven't looked at memory hotplug enough to know why we're open-coding the memblock stuff there. It would be nice to just be able to call memblock_remove() like the pseries hotplug code does.
remove_memory() calls memblock_remove() after confirming that the memory is offlined. That seems sensible to me.
I *think* it is because hot remove mostly comes from when we know about an online region of memory and we want to take it down. In this case we also are trying to discover if those addresses are covered by online memory. Still, I wonder if there are better memblock APIs to do this with? Balbir may have a better idea of that?
