Received: by 2002:a05:6a10:f347:0:0:0:0 with SMTP id d7csp481067pxu; Tue, 1 Dec 2020 16:48:11 -0800 (PST) X-Google-Smtp-Source: ABdhPJzEHkQll23dq+4ZxQW8vpWOJLimUL1jBYu2nLC8ooZszhfvpNjmup6IeDhkWua2U2Q4IOCV X-Received: by 2002:aa7:d1c2:: with SMTP id g2mr264791edp.8.1606870091707; Tue, 01 Dec 2020 16:48:11 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1606870091; cv=none; d=google.com; s=arc-20160816; b=kn7367aGnNLvkJxCXDOXlVu8tznHmcv+6wG800zwZ+JYrbPa7PcDit+JY4yizyOslL U8mqW2NRErDQiWPuXv+Maf3edAcy47mJNqOLzVdhLaUR0fWPxxtfDrjgJkrbNsCW+xuh BwigAI5PHNtjwTseHt4rNMUoa+PHX2vOSE0YxVSQ0IW2J7JVqCyCNhpNl3gP6+/KlzM/ AQtZXc54OQYmjVErgVRb5ckoQXkOv4TaA/RvojrwhY1yOjZ08TcwaS2TTCNBgDHeImLA 2P5dwRL0/D0yih5mKFE9WROVmZvQuDM0i00sOESrDscsdIs2RxVGPEEdGa9HjIG1zQmZ x2sA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:user-agent:in-reply-to:content-disposition :mime-version:references:message-id:subject:cc:to:from:date :dkim-signature; bh=YDYVxD6tkiBev38C3oTUWFTeIWr7XSep6vYBO4i0itk=; b=C55oXHofM7zcnsEPAava4uscnqYiiE9RUIE3zH740pU+qchzVM1gZGNyXMXYx/CXGG GmeTomNGkcZVNtaY8AJpCne9FMU3c0onVxFOVe7NLAt9PhsjD1xpJnbFR09WSAJlqOeZ AefJxqbaaJdc9tK0ZTSWKfO0nL0Xk6wmzS88BPeu9mEQ+Zetz2kQh2Kudb4462c+mw3F izcNywbi+pHfwbo6FRwrOn56NPdbUDa06IT47pnnzJyi5NBCv9l9RIqP5RxgSBFY+UGi GOjC4JDkOo+OmP9iO7u4QytglrAsDE4xeWSYV3gu6xHQE0OlcU4a/KNyJem6gNG43vZM 3Zbg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=jUAd+w9Y; 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; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id cb26si44592edb.382.2020.12.01.16.47.48; Tue, 01 Dec 2020 16:48:11 -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=@redhat.com header.s=mimecast20190719 header.b=jUAd+w9Y; 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; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726771AbgLBAq1 (ORCPT + 99 others); Tue, 1 Dec 2020 19:46:27 -0500 Received: from us-smtp-delivery-124.mimecast.com ([63.128.21.124]:44333 "EHLO us-smtp-delivery-124.mimecast.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726166AbgLBAq1 (ORCPT ); Tue, 1 Dec 2020 19:46:27 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1606869900; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=YDYVxD6tkiBev38C3oTUWFTeIWr7XSep6vYBO4i0itk=; b=jUAd+w9YzDvEHEBr6h4M90iH4kq8VOk8xEqAD0l9g3YVqrSDPbE+9nxqDZU1KOx7LtcYRi MBVJKjQiP8b3bOnPDx5pNRfH7xbMA8/JeUlzoAeoSnNeBJoZ8kWwtiNpX515fr1NAaC0Rg 8hbRVrJFvnNswZczvz1gwFawr4dQZRM= Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-584-eL0NjWgkPnip5CVDTHa03g-1; Tue, 01 Dec 2020 19:44:57 -0500 X-MC-Unique: eL0NjWgkPnip5CVDTHa03g-1 Received: from smtp.corp.redhat.com (int-mx07.intmail.prod.int.phx2.redhat.com [10.5.11.22]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id A12EC805BE1; Wed, 2 Dec 2020 00:44:55 +0000 (UTC) Received: from mail (ovpn-112-118.rdu2.redhat.com [10.10.112.118]) by smtp.corp.redhat.com (Postfix) with ESMTPS id D045C10013BD; Wed, 2 Dec 2020 00:44:51 +0000 (UTC) Date: Tue, 1 Dec 2020 19:44:51 -0500 From: Andrea Arcangeli To: Mike Rapoport Cc: David Hildenbrand , Vlastimil Babka , Mel Gorman , Andrew Morton , linux-mm@kvack.org, Qian Cai , Michal Hocko , linux-kernel@vger.kernel.org, Baoquan He Subject: Re: [PATCH 1/1] mm: compaction: avoid fast_isolate_around() to set pageblock_skip on reserved pages Message-ID: References: <35F8AADA-6CAA-4BD6-A4CF-6F29B3F402A4@redhat.com> <20201125210414.GO123287@linux.ibm.com> <20201126093602.GQ123287@linux.ibm.com> <3bb709a7-6100-aa5c-4125-7ed80c6d9643@redhat.com> <20201126174601.GT123287@linux.ibm.com> <20201129123257.GY123287@linux.ibm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20201129123257.GY123287@linux.ibm.com> User-Agent: Mutt/2.0.2 (2020-11-20) X-Scanned-By: MIMEDefang 2.84 on 10.5.11.22 Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hello Mike, On Sun, Nov 29, 2020 at 02:32:57PM +0200, Mike Rapoport wrote: > Hello Andrea, > > On Thu, Nov 26, 2020 at 07:46:05PM +0200, Mike Rapoport wrote: > > On Thu, Nov 26, 2020 at 11:05:14AM +0100, David Hildenbrand wrote: > > > > Let's try to merge init_unavailable_memory() into memmap_init(). > > Than it'll be able to set zone/nid for those nasty pfns that BIOS > > decided to keep to itself, like in Andrea's case and will also take care > > of struct pages that do not really have a frame in DRAM, but are there > > because of arbitrary section size. > > Did you have a chance to check if this solves your issue? > If yes, I'll resend this as a formal patch. I tested the patch you sent, but it doesn't seem to boot. Reverting it booted. Also I noticed leaving pages uninitialized already happened before and was fixed in 124049decbb121ec32742c94fb5d9d6bed8f24d8 where literally all holes were registered in memblock_reserve() by hand to workaround this very same defect in memblock callee we're fixing again. Then it was lifted in 9fd61bc95130d4971568b89c9548b5e0a4e18e0e since the memblock was supposed to be able to initialize all pages. Since this seems the second time this happens, I'd suggest to change the graceful pfn, 0,0 initialization to memset(page, 0xff, sizeof(struct page)) too like we mentioned earlier and then have at least a DEBUG_SOMETHING=y to search for struct pages with all 1 in page->flags to ensure the boot stage worked right so perhaps there's a graceful notification at boot before a VM_BUG_ON triggers later. The page struct validation could be done based on DEBUG_VM=y too since it won't cause any runtime cost post boot. Thanks, Andrea