On Wed, Nov 07, 2018 at 02:06:55PM +0100, Michal Hocko wrote: > On Wed 07-11-18 23:53:24, Balbir Singh wrote: > > On Wed, Nov 07, 2018 at 08:35:48AM +0100, Michal Hocko wrote: > > > On Wed 07-11-18 07:35:18, Balbir Singh wrote: > [...] > > > > The check seems to be quite aggressive and in a loop that iterates > > > > pages, but has nothing to do with the page, did you mean to make > > > > the check > > > > > > > > zone_idx(page_zone(page)) == ZONE_MOVABLE > > > > > > Does it make any difference? Can we actually encounter a page from a > > > different zone here? > > > > > > > Just to avoid page state related issues, do we want to go ahead > > with the migration if zone_idx(page_zone(page)) != ZONE_MOVABLE. > > Could you be more specific what kind of state related issues you have in > mind? > I was wondering if page_zone() is setup correctly, but it's setup upfront, so I don't think that is ever an issue. > > > > it also skips all checks for pinned pages and other checks > > > > > > Yes, this is intentional and the comment tries to explain why. I wish we > > > could be add a more specific checks for movable pages - e.g. detect long > > > term pins that would prevent migration - but we do not have any facility > > > for that. Please note that the worst case of a false positive is a > > > repeated migration failure and user has a way to break out of migration > > > by a signal. > > > > > > > Basically isolate_pages() will fail as opposed to hotplug failing upfront. > > The basic assertion this patch makes is that all ZONE_MOVABLE pages that > > are not reserved are hotpluggable. > > Yes, that is correct. > I wonder if it is easier to catch a __SetPageReserved() on ZONE_MOVABLE memory at set time, the downside is that we never know if that memory will ever be hot(un)plugged. The patch itself, I think is OK Acked-by: Balbir Singh <bsingharora@xxxxxxxxx> Balbir Singh.
