On 25.11.19 14:09, Michal Hocko wrote: > On Tue 19-11-19 12:52:37, David Hildenbrand wrote: >> Our onlining/offlining code is unnecessarily complicated. Only memory >> blocks added during boot can have holes (a range that is not >> IORESOURCE_SYSTEM_RAM). Hotplugged memory never has holes (e.g., see >> add_memory_resource()). All memory blocks that belong to boot memory are >> already online. >> >> Note that boot memory can have holes and the memmap of the holes is marked >> PG_reserved. However, also memory allocated early during boot is >> PG_reserved - basically every page of boot memory that is not given to the >> buddy is PG_reserved. >> >> Therefore, when we stop allowing to offline memory blocks with holes, we >> implicitly no longer have to deal with onlining memory blocks with holes. >> E.g., online_pages() will do a >> walk_system_ram_range(..., online_pages_range), whereby >> online_pages_range() will effectively only free the memory holes not >> falling into a hole to the buddy. The other pages (holes) are kept >> PG_reserved (via move_pfn_range_to_zone()->memmap_init_zone()). >> >> This allows to simplify the code. For example, we no longer have to >> worry about marking pages that fall into memory holes PG_reserved when >> onlining memory. We can stop setting pages PG_reserved completely in >> memmap_init_zone(). >> >> Offlining memory blocks added during boot is usually not guaranteed to work >> either way (unmovable data might have easily ended up on that memory during >> boot). So stopping to do that should not really hurt. Also, people are not >> even aware of a setup where onlining/offlining of memory blocks with >> holes used to work reliably (see [1] and [2] especially regarding the >> hotplug path) - I doubt it worked reliably. >> >> For the use case of offlining memory to unplug DIMMs, we should see no >> change. (holes on DIMMs would be weird). >> >> Please note that hardware errors (PG_hwpoison) are not memory holes and >> are not affected by this change when offlining. >> >> [1] https://lkml.org/lkml/2019/10/22/135 >> [2] https://lkml.org/lkml/2019/8/14/1365 > > Please do not use lkml.org links, they tend to break longterm. Use > http://lkml.kernel.org/r/$msg_id instead. Thanks for the tip! I read a couple of times that these links are problematic but never knew what to use instead ... -- Thanks, David / dhildenb
