On Wed 18-09-19 10:52:25, Alexander Duyck wrote: [...] > In order to try and keep the time needed to find a non-reported page to > a minimum we maintain a "reported_boundary" pointer. This pointer is used > by the get_unreported_pages iterator to determine at what point it should > resume searching for non-reported pages. In order to guarantee pages do > not get past the scan I have modified add_to_free_list_tail so that it > will not insert pages behind the reported_boundary. > > If another process needs to perform a massive manipulation of the free > list, such as compaction, it can either reset a given individual boundary > which will push the boundary back to the list_head, or it can clear the > bit indicating the zone is actively processing which will result in the > reporting process resetting all of the boundaries for a given zone. Is this any different from the previous version? The last review feedback (both from me and Mel) was that we are not happy to have an externally imposed constrains on how the page allocator is supposed to maintain its free lists. If this is really the only way to go forward then I would like to hear very convincing arguments about other approaches not being feasible. There are none in this cover letter unfortunately. This will be really a hard sell without them. -- Michal Hocko SUSE Labs
