On Thu 26-04-18 17:30:47, David Hildenbrand wrote: > On 19.04.2018 09:33, Michal Hocko wrote: > > On Wed 18-04-18 17:46:25, David Hildenbrand wrote: > > [...] > >> BTW I was able to easily produce the case where do_migrate_range() would > >> loop for ever (well at least for multiple minutes, but I assume this > >> would have went on :) ) > > > > I am definitely interested to hear details. > > > > migrate_pages() seems to be returning > 0 all the time. Seems to come > from too many -EAGAIN from unmap_and_move(). > > This in return (did not go further down that road) can be as simple as > trylock_page() failing. Yes but we assume that nobody holds the lock for ever so sooner or later we should be able to get the lock. > Of course, we could have other permanent errors here (-ENOMEM). > __offline_pages() ignores all errors coming from do_migrate_range(). So > in theory, this can take forever - at least not what I want for my use > case. I want it to fail fast. "if this block cannot be offlined, try > another one". > > I wonder if it is the right thing to do in __offline_pages() to ignore > even permanent errors. Anyhow, I think I'll need some way of telling > offline_pages "please don't retry forever". Well, it would be really great to find a way to distinguish permanent errors from temporary ones. But I am not sure this is very easy. Anyway, we should be only looking at migratable pages at this stage of the offline so the migration should eventually succeed. We have a bug if this is not a case and we should address it. Find the page which fails to migrate and see who keeps us from migrating it. This might be a page pin abuser or something else. That is why I've said I am interested in details. -- Michal Hocko SUSE Labs
