Messages in this thread | | | From | Pavel Tatashin <> | Date | Wed, 2 Sep 2020 08:51:06 -0400 | Subject | Re: [PATCH v2 00/28] The new cgroup slab memory controller |
| |
> > > Thread #1: memory hot-remove systemd service > > > Loops indefinitely, because if there is something still to be migrated > > > this loop never terminates. However, this loop can be terminated via > > > signal from systemd after timeout. > > > __offline_pages() > > > do { > > > pfn = scan_movable_pages(pfn, end_pfn); > > > # Returns 0, meaning there is nothing available to > > > # migrate, no page is PageLRU(page) > > > ... > > > ret = walk_system_ram_range(start_pfn, end_pfn - start_pfn, > > > NULL, check_pages_isolated_cb); > > > # Returns -EBUSY, meaning there is at least one PFN that > > > # still has to be migrated. > > > } while (ret); >
Hi Micahl,
> This shouldn't really happen. What does prevent from this to proceed? > Did you manage to catch the specific pfn and what is it used for?
I did.
> start_isolate_page_range and scan_movable_pages should fail if there is > any memory that cannot be migrated permanently. This is something that > we should focus on when debugging.
I was hitting this issue: mm/memory_hotplug: drain per-cpu pages again during memory offline https://lore.kernel.org/lkml/20200901124615.137200-1-pasha.tatashin@soleen.com
Once the pcp drain race is fixed, this particular deadlock becomes irrelavent.
The lock ordering, however, cgroup_mutex -> mem_hotplug_lock is bad, and the first race condition that I was hitting and described above is still present. For now I added a temporary workaround by using save to file instead of piping the core during shutdown. I am glad the mainline is fixed, but stables should also have some kind of fix for this problem.
Pasha
| |