From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-2.5 required=3.0 tests=MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_1 autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id CAA1ACA9EAF for ; Thu, 24 Oct 2019 08:42:50 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 7726C205F4 for ; Thu, 24 Oct 2019 08:42:50 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 7726C205F4 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=kernel.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id C5E136B0005; Thu, 24 Oct 2019 04:42:49 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id C0E796B0006; Thu, 24 Oct 2019 04:42:49 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id AFC2D6B0007; Thu, 24 Oct 2019 04:42:49 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0213.hostedemail.com [216.40.44.213]) by kanga.kvack.org (Postfix) with ESMTP id 90A856B0005 for ; Thu, 24 Oct 2019 04:42:49 -0400 (EDT) Received: from smtpin24.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay05.hostedemail.com (Postfix) with SMTP id 45DCE181AEF3C for ; Thu, 24 Oct 2019 08:42:49 +0000 (UTC) X-FDA: 76078037658.24.watch97_52c934087d94b X-HE-Tag: watch97_52c934087d94b X-Filterd-Recvd-Size: 3922 Received: from mx1.suse.de (mx2.suse.de [195.135.220.15]) by imf08.hostedemail.com (Postfix) with ESMTP for ; Thu, 24 Oct 2019 08:42:48 +0000 (UTC) X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.220.254]) by mx1.suse.de (Postfix) with ESMTP id 8D604B597; Thu, 24 Oct 2019 08:42:46 +0000 (UTC) Date: Thu, 24 Oct 2019 10:42:41 +0200 From: Michal Hocko To: David Hildenbrand Cc: linux-kernel@vger.kernel.org, linux-mm@kvack.org, virtualization@lists.linux-foundation.org, Andrea Arcangeli , Andrew Morton , Juergen Gross , Pavel Tatashin , Alexander Duyck , Anthony Yznaga , Vlastimil Babka , Johannes Weiner , Oscar Salvador , Pingfan Liu , Qian Cai , Dan Williams , Mel Gorman , Mike Rapoport , Wei Yang , Alexander Potapenko , Anshuman Khandual , Jason Gunthorpe , Stephen Rothwell , Mauro Carvalho Chehab , Matthew Wilcox , Yu Zhao , Minchan Kim , Yang Shi , Ira Weiny , Andrey Ryabinin Subject: Re: [PATCH RFC v3 6/9] mm: Allow to offline PageOffline() pages with a reference count of 0 Message-ID: <20191024084241.GV17610@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-Disposition: inline In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: 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