From mboxrd@z Thu Jan 1 00:00:00 1970 From: Michal Hocko Subject: Re: [PATCH RFC v3 6/9] mm: Allow to offline PageOffline() pages with a reference count of 0 Date: Thu, 24 Oct 2019 10:42:41 +0200 Message-ID: <20191024084241.GV17610__25491.4393344492$1571906580$gmane$org@dhcp22.suse.cz> References: <20191016140350.GD317@dhcp22.suse.cz> <7c7bef01-f904-904a-b0a7-f7b514b8bda8@redhat.com> <20191018081524.GD5017@dhcp22.suse.cz> <83d0a961-952d-21e4-74df-267912b7b6fa@redhat.com> <20191018111843.GH5017@dhcp22.suse.cz> <709d39aa-a7ba-97aa-e66b-e2fec2fdf3c4@redhat.com> <20191022122326.GL9379@dhcp22.suse.cz> <20191023094345.GL754@dhcp22.suse.cz> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Content-Disposition: inline In-Reply-To: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: virtualization-bounces@lists.linux-foundation.org Errors-To: virtualization-bounces@lists.linux-foundation.org To: David Hildenbrand Cc: Pingfan Liu , virtualization@lists.linux-foundation.org, linux-mm@kvack.org, Alexander Potapenko , Mauro Carvalho Chehab , Alexander Duyck , Ira Weiny , Andrea Arcangeli , Stephen Rothwell , Yu Zhao , Matthew Wilcox , Jason Gunthorpe , Anthony Yznaga , Pavel Tatashin , Anshuman Khandual , Mike Rapoport , Qian Cai , Andrey Ryabinin , Dan Williams , Vlastimil Babka , Oscar Salvador , Juergen Gross , Yang Shi List-Id: virtualization@lists.linuxfoundation.org On Wed 23-10-19 12:03:51, David Hildenbrand wrote: > >Do you see any downsides? > > The only downside I see is that we get more false negatives on > has_unmovable_pages(), eventually resulting in the offlining stage after > isolation to loop forever (as some PageOffline() pages are not movable > (especially, XEN balloon, HyperV balloon), there won't be progress). > > I somewhat don't like forcing everybody that uses PageOffline() (especially > all users of balloon compaction) to implement memory notifiers just to avoid > that. Maybe, we even want to use PageOffline() in the future in the core > (e.g., for memory holes instead of PG_reserved or similar). There is only a handful of those and we need to deal with them anyway. If you do not want to enforce them to create their own notifiers then we can accomodate the hotplug code. __test_page_isolated_in_pageblock resp. the call chain up can distinguish temporary and permanent failures (EAGAIN vs. EBUSY). The current state when we always return EBUSY and keep retrying for ever is not optimal at all, right? A referenced PageOffline could be an example of EBUSY all other failures where we are effectively waiting for pages to get freed finaly would be EAGAIN. It is a bit late in the process because a large portion of the work has been done already but this doesn't sound like something to lose sleep over. -- Michal Hocko SUSE Labs