Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > linux.kernel > #1731554

Re: [PATCH 1/2] mm, memory_hotplug: do not fail offlining too early

From Vlastimil Babka <vbabka@suse.cz>
Newsgroups linux.kernel
Subject Re: [PATCH 1/2] mm, memory_hotplug: do not fail offlining too early
Date 2017-09-13 13:50 +0200
Message-ID <upel5-6QI-41@gated-at.bofh.it> (permalink)
References <ulUVz-38W-9@gated-at.bofh.it> <ulUVz-38W-7@gated-at.bofh.it> <unvgm-1Cc-29@gated-at.bofh.it> <uos6J-jr-9@gated-at.bofh.it>
Organization linux.* mail to news gateway

Show all headers | View raw


On 09/11/2017 10:17 AM, Michal Hocko wrote:
> On Fri 08-09-17 19:26:06, Vlastimil Babka wrote:
>> On 09/04/2017 10:21 AM, Michal Hocko wrote:
>>> From: Michal Hocko <mhocko@suse.com>
>>>
>>> Fix this by removing the max retry count and only rely on the timeout
>>> resp. interruption by a signal from the userspace. Also retry rather
>>> than fail when check_pages_isolated sees some !free pages because those
>>> could be a result of the race as well.
>>>
>>> Signed-off-by: Michal Hocko <mhocko@suse.com>
>>
>> Even within a movable node where has_unmovable_pages() is a non-issue, you could
>> have pinned movable pages where the pinning is not temporary.
> 
> Who would pin those pages? Such a page would be unreclaimable as well
> and thus a memory leak and I would argue it would be a bug.

I don't know who exactly, but generally it's a problem for CMA and a
reason why there was some effort from PeterZ to introduce an API for
long-term pinning.

>> So after this
>> patch, this will really keep retrying forever. I'm not saying it's wrong, just
>> pointing it out, since the changelog seems to assume there would be only
>> temporary failures possible and thus unbound retries are always correct.
>> The obvious problem if we wanted to avoid this, is how to recognize
>> non-temporary failures...
> 
> Yes, we should be able to distinguish the two and hopefully we can teach
> the migration code to distinguish between EBUSY (likely permanent) and
> EGAIN (temporal) failure. This sound like something we should aim for
> longterm I guess. Anyway as I've said in other email. If somebody really
> wants to have a guaratee of a bounded retry then it is trivial to set up
> an alarm and send a signal itself to bail out.

Sure, I would just be careful about not breaking existing userspace
(udev?) when offline triggered via ACPI from some management interface
(or whatever the exact mechanism is).

> Do you think that the changelog should be more clear about this?

It certainly wouldn't hurt :)

Back to linux.kernel | Previous | NextPrevious in thread | Next in thread | Find similar | Unroll thread


Thread

Re: [PATCH 1/2] mm, memory_hotplug: do not fail offlining too early Michal Hocko <mhocko@kernel.org> - 2017-09-11 10:20 +0200
  Re: [PATCH 1/2] mm, memory_hotplug: do not fail offlining too early Vlastimil Babka <vbabka@suse.cz> - 2017-09-13 13:50 +0200
    Re: [PATCH 1/2] mm, memory_hotplug: do not fail offlining too early Vlastimil Babka <vbabka@suse.cz> - 2017-09-13 14:20 +0200
      Re: [PATCH 1/2] mm, memory_hotplug: do not fail offlining too early Michal Hocko <mhocko@kernel.org> - 2017-09-13 14:40 +0200
    Re: [PATCH 1/2] mm, memory_hotplug: do not fail offlining too early Michal Hocko <mhocko@kernel.org> - 2017-09-13 14:20 +0200
    Re: [PATCH 1/2] mm, memory_hotplug: do not fail offlining too early Michal Hocko <mhocko@kernel.org> - 2017-09-13 14:20 +0200

csiph-web