Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.kernel > #1731554
| 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 |
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 | Next — Previous in thread | Next in thread | Find similar | Unroll 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