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

[David Hildenbrand <david@redhat.com>]

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