[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20191024084241.GV17610@dhcp22.suse.cz>
Date: Thu, 24 Oct 2019 10:42:41 +0200
From: Michal Hocko <mhocko@...nel.org>
To: David Hildenbrand <david@...hat.com>
Cc: linux-kernel@...r.kernel.org, linux-mm@...ck.org,
virtualization@...ts.linux-foundation.org,
Andrea Arcangeli <aarcange@...hat.com>,
Andrew Morton <akpm@...ux-foundation.org>,
Juergen Gross <jgross@...e.com>,
Pavel Tatashin <pavel.tatashin@...rosoft.com>,
Alexander Duyck <alexander.h.duyck@...ux.intel.com>,
Anthony Yznaga <anthony.yznaga@...cle.com>,
Vlastimil Babka <vbabka@...e.cz>,
Johannes Weiner <hannes@...xchg.org>,
Oscar Salvador <osalvador@...e.de>,
Pingfan Liu <kernelfans@...il.com>, Qian Cai <cai@....pw>,
Dan Williams <dan.j.williams@...el.com>,
Mel Gorman <mgorman@...hsingularity.net>,
Mike Rapoport <rppt@...ux.vnet.ibm.com>,
Wei Yang <richardw.yang@...ux.intel.com>,
Alexander Potapenko <glider@...gle.com>,
Anshuman Khandual <anshuman.khandual@....com>,
Jason Gunthorpe <jgg@...pe.ca>,
Stephen Rothwell <sfr@...b.auug.org.au>,
Mauro Carvalho Chehab <mchehab+samsung@...nel.org>,
Matthew Wilcox <willy@...radead.org>,
Yu Zhao <yuzhao@...gle.com>, Minchan Kim <minchan@...nel.org>,
Yang Shi <yang.shi@...ux.alibaba.com>,
Ira Weiny <ira.weiny@...el.com>,
Andrey Ryabinin <aryabinin@...tuozzo.com>
Subject: Re: [PATCH RFC v3 6/9] mm: Allow to offline PageOffline() pages with
a reference count of 0
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
Powered by blists - more mailing lists