From patchwork Wed May 23 08:16:09 2018 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Michal Hocko X-Patchwork-Id: 10420565 Return-Path: Received: from mail.wl.linuxfoundation.org (pdx-wl-mail.web.codeaurora.org [172.30.200.125]) by pdx-korg-patchwork.web.codeaurora.org (Postfix) with ESMTP id A4EEB60327 for ; Wed, 23 May 2018 08:16:21 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 934A628E39 for ; Wed, 23 May 2018 08:16:21 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id 86C3428E3C; Wed, 23 May 2018 08:16:21 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on pdx-wl-mail.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-2.9 required=2.0 tests=BAYES_00, MAILING_LIST_MULTI, RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.1 Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 1FDD628E39 for ; Wed, 23 May 2018 08:16:15 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 4666E6B0006; Wed, 23 May 2018 04:16:14 -0400 (EDT) Delivered-To: linux-mm-outgoing@kvack.org Received: by kanga.kvack.org (Postfix, from userid 40) id 416A36B0007; Wed, 23 May 2018 04:16:14 -0400 (EDT) X-Original-To: int-list-linux-mm@kvack.org X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 32E156B0008; Wed, 23 May 2018 04:16:14 -0400 (EDT) X-Original-To: linux-mm@kvack.org X-Delivered-To: linux-mm@kvack.org Received: from mail-pl0-f70.google.com (mail-pl0-f70.google.com [209.85.160.70]) by kanga.kvack.org (Postfix) with ESMTP id E22C46B0006 for ; Wed, 23 May 2018 04:16:13 -0400 (EDT) Received: by mail-pl0-f70.google.com with SMTP id x32-v6so13713482pld.16 for ; Wed, 23 May 2018 01:16:13 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-original-authentication-results:x-gm-message-state:date:from:to :cc:subject:message-id:references:mime-version:content-disposition :in-reply-to:user-agent; bh=Ng5WHFC9Akzk7CQdYbJjtA4baWJRr3/cF9PfSb650KA=; b=oq02R4NrH/daH7R3VTl1FEums8WOa6T1N7pNzgqFgs8dAj+3/fWu1eHDz2HPsgK21u J0PP9qm5QuWmzKK8e7XKSVEYjj1Be9+JtQleuhJAFNLScJPdo82rfWCJhxNLtY3rf+Qz SWFGkX8NNJLn8dhQcx2goz4lz9X7t09323NxTkkRlfcmxZq69UfLtFACwpWtKCZRl/pr Vj8TWXKP+XpBCWIqliRXX4y04k+hzhdhj+XU0Gn17hx9pG+fuj3dH/hf2/a/OnW3d0Nv nSRs1pJriU9VTOWYfEXqTLu/7zEdX2u+k8alrX4W2w6ncxmU6Wl4Qb97wL7gl1H2XmVP GSKA== X-Original-Authentication-Results: mx.google.com; spf=pass (google.com: domain of mhocko@suse.com designates 195.135.220.15 as permitted sender) smtp.mailfrom=mhocko@suse.com X-Gm-Message-State: ALKqPwccoooTJ1Q/sorQjP2EBQvYMasBxC7hWejc34QP4E53YNA8nzBr TCkv4QbihTVyfiv0zJCuQqSXSuG4lC8miIijNeaRxhLQz/D91T7bVzxi4ziOcAWc+VEdhqYspv+ O+RmKBhbadL8dM01iUaRfnQyJsBHDUna2RA3A73L7Gqd5hQCttyGRcO5QlgcIOY9sBg== X-Received: by 2002:a65:4e03:: with SMTP id r3-v6mr1543310pgt.121.1527063373591; Wed, 23 May 2018 01:16:13 -0700 (PDT) X-Google-Smtp-Source: AB8JxZpc2RqAm+kh0CTRp66l5Q7wHSb2/jEjyxN9RjNaWR5mdrplTOEmnzgNa8e+qM9a3q9U9jiO X-Received: by 2002:a65:4e03:: with SMTP id r3-v6mr1543268pgt.121.1527063372751; Wed, 23 May 2018 01:16:12 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1527063372; cv=none; d=google.com; s=arc-20160816; b=ieC+xNKtaqq/QwIgknyM27gUhxix7bdhkB1XDsyzaU0WG3edLUj4DEP9zSBVT/Q+GX B97FoWxPpfKowxc8fW8glIB3SOAlXsmdl5JgmVYzQ+DUJ1fdoRlbFICy85ezWriWybVK fqKOJPEOB1JGnnkFbs6RHhLEk3kcJCFa9guDQOZ04leESl21Lt7VSKdloFxxjo0CScK2 geOWT4ayFvMB5453TqSLnaHfGX2XxUAM+ycVPRIzA5owNgdkjn/hKJqqExontLxsNoNM 67PvOtkduH7oNeLKZ2/R9VLpFmV8eub2GrT/ainujbatXTYc6+kH3p9QGzQ0hKsFeTr0 iBTw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=user-agent:in-reply-to:content-disposition:mime-version:references :message-id:subject:cc:to:from:date:arc-authentication-results; bh=Ng5WHFC9Akzk7CQdYbJjtA4baWJRr3/cF9PfSb650KA=; b=d87k7EDSuOcqoh9LTjuLGr+UUDoIBI1a20aAWnOKqGWL9oSKoOH+pUvdrn2DvhmCBm jb7iJNv9kTdNyBvZ1rrr/FoA+boIVqKHjefMEOGmNIrvkch8Vx6ir79F9CxbQ+trx7Wb ZcihnrLZwNuigq+fVABqm9UsA56Ma5uhnSVXpYanJl3xn+f2EZ1xglbSXvdthQwpCa2y fPDhk/IyRfJQ6c4SUPyxRaMKt85I3dZwRIiwoCZlv2mar2WXIAg511NAxSyRxYvubkbX dmbyOi5ptJoii3g7Gb7fxvcvgOPIUEIHPnO9MkFCEqSz4MSYwI5YDSSwrA2Iv4wc6rS+ RXtA== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of mhocko@suse.com designates 195.135.220.15 as permitted sender) smtp.mailfrom=mhocko@suse.com Received: from mx2.suse.de (mx2.suse.de. [195.135.220.15]) by mx.google.com with ESMTPS id u6-v6si18515239pls.462.2018.05.23.01.16.12 for (version=TLS1 cipher=AES128-SHA bits=128/128); Wed, 23 May 2018 01:16:12 -0700 (PDT) Received-SPF: pass (google.com: domain of mhocko@suse.com designates 195.135.220.15 as permitted sender) client-ip=195.135.220.15; Authentication-Results: mx.google.com; spf=pass (google.com: domain of mhocko@suse.com designates 195.135.220.15 as permitted sender) smtp.mailfrom=mhocko@suse.com X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (charybdis-ext.suse.de [195.135.220.254]) by mx2.suse.de (Postfix) with ESMTP id CEAC7ACDD; Wed, 23 May 2018 08:16:10 +0000 (UTC) Date: Wed, 23 May 2018 10:16:09 +0200 From: Michal Hocko To: Oscar Salvador Cc: linux-mm@kvack.org, vbabka@suse.cz, pasha.tatashin@oracle.com, akpm@linux-foundation.org Subject: Re: [RFC] Checking for error code in __offline_pages Message-ID: <20180523081609.GG20441@dhcp22.suse.cz> References: <20180523073547.GA29266@techadventures.net> <20180523075239.GF20441@dhcp22.suse.cz> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20180523075239.GF20441@dhcp22.suse.cz> User-Agent: Mutt/1.9.5 (2018-04-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: X-Virus-Scanned: ClamAV using ClamSMTP On Wed 23-05-18 09:52:39, Michal Hocko wrote: [...] > Yeah, the current code is far from optimal. We > used to have a retry count but that one was removed exactly because of > premature failures. There are three things here > 1) zone_movable should contain any bootmem or otherwise non-migrateable > pages > 2) start_isolate_page_range should fail when seeing such pages - maybe > has_unmovable_pages is overly optimistic and it should check all > pages even in movable zones. > 3) migrate_pages should really tell us whether the failure is temporal > or permanent. I am not sure we can do that easily though. 2) should be the most simple one for now. Could you give it a try? Btw. the exact configuration that led to boothmem pages in zone_movable would be really appreciated: Tested-by: Oscar Salvador --- From 6aa144a9b1c01255c89a4592221d706ccc4b4eea Mon Sep 17 00:00:00 2001 From: Michal Hocko Date: Wed, 23 May 2018 10:04:20 +0200 Subject: [PATCH] mm, memory_hotplug: make has_unmovable_pages more robust Oscar has reported: : Due to an unfortunate setting with movablecore, memblocks containing bootmem : memory (pages marked by get_page_bootmem()) ended up marked in zone_movable. : So while trying to remove that memory, the system failed in do_migrate_range : and __offline_pages never returned. This is because we rely on start_isolate_page_range resp. has_unmovable_pages to do their jobb. The first one isolates the whole range to be offlined so that we do not allocate from it anymore and the later makes sure we are not stumbling over non-migrateable pages. has_unmovable_pages is overly optimistic, however. It doesn't check all the pages if we are withing zone_movable because we rely that those pages will be always migrateable. As it turns out we are still not perfect there. While bootmem pages in zonemovable sound like a clear bug which should be fixed let's remove the optimization for now and warn if we encounter unmovable pages in zone_movable in the meantime. That should help for now at least. Btw. this wasn't a real problem until 72b39cfc4d75 ("mm, memory_hotplug: do not fail offlining too early") because we used to have a small number of retries and then failed. This turned out to be too fragile though. Reported-by: Oscar Salvador Signed-off-by: Michal Hocko --- mm/page_alloc.c | 16 ++++++++++------ 1 file changed, 10 insertions(+), 6 deletions(-) diff --git a/mm/page_alloc.c b/mm/page_alloc.c index 3c6f4008ea55..b9a45753244d 100644 --- a/mm/page_alloc.c +++ b/mm/page_alloc.c @@ -7629,11 +7629,12 @@ bool has_unmovable_pages(struct zone *zone, struct page *page, int count, unsigned long pfn, iter, found; /* - * For avoiding noise data, lru_add_drain_all() should be called - * If ZONE_MOVABLE, the zone never contains unmovable pages + * TODO we could make this much more efficient by not checking every + * page in the range if we know all of them are in MOVABLE_ZONE and + * that the movable zone guarantees that pages are migratable but + * the later is not the case right now unfortunatelly. E.g. movablecore + * can still lead to having bootmem allocations in zone_movable. */ - if (zone_idx(zone) == ZONE_MOVABLE) - return false; /* * CMA allocations (alloc_contig_range) really need to mark isolate @@ -7654,7 +7655,7 @@ bool has_unmovable_pages(struct zone *zone, struct page *page, int count, page = pfn_to_page(check); if (PageReserved(page)) - return true; + goto unmovable; /* * Hugepages are not in LRU lists, but they're movable. @@ -7704,9 +7705,12 @@ bool has_unmovable_pages(struct zone *zone, struct page *page, int count, * page at boot. */ if (found > count) - return true; + goto unmovable; } return false; +unmovable: + WARN_ON_ONCE(zone_idx(zone) == ZONE_MOVABLE); + return true; } #if (defined(CONFIG_MEMORY_ISOLATION) && defined(CONFIG_COMPACTION)) || defined(CONFIG_CMA)