On Wed 05-04-17 08:42:39, Michal Hocko wrote: > On Tue 04-04-17 16:43:39, Reza Arbab wrote: > > On Tue, Apr 04, 2017 at 09:41:22PM +0200, Michal Hocko wrote: > > >On Tue 04-04-17 13:30:13, Reza Arbab wrote: > > >>I think I found another edge case. You > > >>get an oops when removing all of a node's memory: > > >> > > >>__nr_to_section > > >>__pfn_to_section > > >>find_biggest_section_pfn > > >>shrink_pgdat_span > > >>__remove_zone > > >>__remove_section > > >>__remove_pages > > >>arch_remove_memory > > >>remove_memory > > > > > >Is this something new or an old issue? I believe the state after the > > >online should be the same as before. So if you onlined the full node > > >then there shouldn't be any difference. Let me have a look... > > > > It's new. Without this patchset, I can repeatedly > > add_memory()->online_movable->offline->remove_memory() all of a node's > > memory. > > This is quite unexpected because the code obviously cannot handle the > first memory section. Could you paste /proc/zoneinfo and > grep . -r /sys/devices/system/memory/auto_online_blocks/memory*, after > onlining for both patched and unpatched kernels? Btw. how do you test this? I am really surprised you managed to hotremove such a low pfn range. -- Michal Hocko SUSE Labs -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@xxxxxxxxx. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>
