On Wed, 22 Jan 2020, Michal Hocko wrote: > > The current code in 5.4 from commit 87eaceb3faa59 places any migrated > > compound page onto the deferred split queue of the destination memcg > > regardless of whether it has a mapping pmd > > (list_empty(page_deferred_list()) was already false) or it does not have a > > mapping pmd (but is now on the wrong queue). For the latter, > > can_split_huge_page() can help for the actual split but not for the > > removal of the page that is now erroneously on the queue. > > Does that mean that those fully mapped THPs are not going to be split? > It believe it should but deferred_split_scan() also won't take it off the wrong split queue so it will remain there and any other checks for page_deferred_list(page) will succeed. > > For the former, > > memcg reclaim would not see the pages that it should split under memcg > > pressure so we'll see the same memcg oom conditions we saw before the > > deferred split shrinker became SHRINKER_MEMCG_AWARE: unnecessary ooms. > > OK, this is yet another user visibile effect and it would be better to > mention it explicitly in the changelog. > Ok, feel free to add to the last paragraph: Memcg reclaim would not see the compound pages that it should split under memcg pressure so we'll otherwise see the same memcg oom conditions we saw before the deferred split shrinker became SHRINKER_MEMCG_AWARE: unnecessary ooms.
