On 29.04.2018 23:05, Michal Hocko wrote: > 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. > Yes, I am definitely planning to look into the details (because for my work it implies needlessly trying to offline pages, which is overhead). For now I think - even having that sorted out - that I'll need a way to tell offline_pages() to fail fast (as you mentioned: distinguishing permanent from temporary errors might not be easy). offline_pages() is historically only triggered by the user, who can simply decide to stop (-EINTR) if it takes to long. Let's discuss with the next RFC. -- Thanks, David / dhildenb
