Re: [PATCH RFC 0/8] mm: online/offline 4MB chunks controlled by device driver

[Michal Hocko <mhocko@kernel.org>]

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