Received: by 2002:a05:6a10:f347:0:0:0:0 with SMTP id d7csp924491pxu; Fri, 4 Dec 2020 21:14:03 -0800 (PST) X-Google-Smtp-Source: ABdhPJzS3nTyFMYzdnRCArcjMBoqR43QPtuxHsFJixiXQxt3lrP3XTkeOQKAvk6YuZnPDMedrWoh X-Received: by 2002:a17:906:8693:: with SMTP id g19mr10702666ejx.111.1607145242866; Fri, 04 Dec 2020 21:14:02 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1607145242; cv=none; d=google.com; s=arc-20160816; b=NyzlaEqn4JNhiYt0rcWy0wMMVsoDGvhrxjQ94jsVbAw9/zFyt/QIRvwpod63ZzLi/b HtHBfqfa5UAExWNWS23UQvDuF35CiukDJbiOoEl9JbJ45S+ftwR7imb5xtxtBv89pHad 4jkGP5eTVuC/UF+OcAePNRtoJ7iWSIGuKuxb5lETnjfzP3X8amUVXr2urQlDvL+0/K50 lM/pDDvergZjypdiP0F1baNHCnNCv5g5Dv30NDJdRXvZOVml05JE4oK/guz/Yi8zCltB RjzuhrVHyrwXjZmn4NRAKYwEYGG+/9Cbf5KPpNTz/GfVDG3exw9EFVUEpR/FzLlcfEL1 lg8w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :references:in-reply-to:message-id:subject:cc:to:from:dkim-signature :date; bh=wMr5c0jkEZNLn19C3nVJv6CRVBWrxW22OKk3xjv8DfI=; b=OCa5nDH6EArW7zCxY80UCjw0+zZtKD/yKO1pubxkLlcnfqLNn84Qz+59A4UiZkGnhX cFsMoaC++QiCf4UXNU/g8bahBdB1aS5sq8dDVvoWPEqkFNoQ6/fsWtjCQmuXl+tEqDSu 7+hRAvI/bKMKMM8kzYP+2AiH+TqxBLTN+LrGVXVY7Syp0yp/hDuTA0qlSzE8YSJICKzD jS6fR8mB0td8qQAYqvGp6RsTGWR7B2E/dTEKCB/z4Rs5CJp32QsJ1s/6qCMrtLF+pl+W H33slrVD+TaAWwIpkgBipBeK65dij1aQsYlIMzGoY/SWG1754WJ1rTKRM0yD3l1Hernt sFbg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linux-foundation.org header.s=korg header.b=nF5Q5QDc; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id k23si2607817ejk.521.2020.12.04.21.13.40; Fri, 04 Dec 2020 21:14:02 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@linux-foundation.org header.s=korg header.b=nF5Q5QDc; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726146AbgLEFLS (ORCPT + 99 others); Sat, 5 Dec 2020 00:11:18 -0500 Received: from mail.kernel.org ([198.145.29.99]:49678 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725536AbgLEFLS (ORCPT ); Sat, 5 Dec 2020 00:11:18 -0500 Date: Fri, 4 Dec 2020 21:10:36 -0800 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linux-foundation.org; s=korg; t=1607145037; bh=l+JQ73ajYdzS8o0e4+RNL0uZERAgdcyKPx/vWiSbNyk=; h=From:To:Cc:Subject:In-Reply-To:References:From; b=nF5Q5QDcqVHZfmoziV4sdgz8hYItV0/1Pxi4pbrQaH5a3ewuAgCe0dIwKtMQJhclR 4rleG5epn6dlUdW4J22MAUe1xymaLakuAF1502BoEtzRBpyU7h8rGPgoFqLOXuu5DJ rUzzjmOpyAiZ1dOBfPPxf85wY9EZ91fJb1ZUeN1o= From: Andrew Morton To: Andrea Arcangeli Cc: linux-mm@kvack.org, Mike Rapoport Baoquan He <"rppt@kernel.orgbhe"@redhat.com>, David Hildenbrand , Mel Gorman , Michal Hocko , Qian Cai , Vlastimil Babka , linux-kernel@vger.kernel.org Subject: Re: [PATCH 0/1] mm: initialize struct pages in reserved regions outside of the zone ranges Message-Id: <20201204211036.48092c4bc83dabd1419f9c71@linux-foundation.org> In-Reply-To: <20201205013238.21663-1-aarcange@redhat.com> References: <20201201181502.2340-1-rppt@kernel.org> <20201205013238.21663-1-aarcange@redhat.com> X-Mailer: Sylpheed 3.5.1 (GTK+ 2.24.31; x86_64-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, 4 Dec 2020 20:32:37 -0500 Andrea Arcangeli wrote: > I'm running with these patch applied on all instances as solution to > the compaction crashes that started to trigger after the v5.9 > upgrade. It's applied on top of > https://lore.kernel.org/lkml/20201201181502.2340-1-rppt@kernel.org so > that it boots and works fine even when there are memblock.reserved > regions that don't overlap with the memblock.memory (as pfn 0 which is > in memblock.reserved but not added to memblock.memory). Are you planning on preparing an applicable-to-mainline version of this?