Received: by 2002:a05:6a10:8c0a:0:0:0:0 with SMTP id go10csp1122136pxb; Fri, 26 Feb 2021 03:10:04 -0800 (PST) X-Google-Smtp-Source: ABdhPJyEOAKzNxTXvmebIqgQlIBbEL2kLbe2MNGTffC0BJNvXoCzxxeaoJ9yKl+Pbtekvc4YVFj6 X-Received: by 2002:a17:907:9619:: with SMTP id gb25mr2716991ejc.64.1614337804416; Fri, 26 Feb 2021 03:10:04 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1614337804; cv=none; d=google.com; s=arc-20160816; b=Z3v7w9Pr/uIvKUvCMTgZq0DRo0gUrFIfKmmSoBl8HaRDtSFexZZpdoPG683kNZyPTw jBOEpcMY4sbOv32yPMnkayFO/loUUitrLC/uXwpTe2STQistSew4ypO/uH/T4IXu/XyF Pf/TSA7PXRswFg/+3Bk6q617DSlEjl7qC7HyJgThxEdg3ue9J7s1zYYSxMtW61cLcYh+ ovYu8AeSsPCWyH6M4YYIslGlCPpEr9Ah+3u5v3dk2m8uT/wkix/wzsd3i7StjnXdHgYI eYCPRTTg8m/80tXkb3kw7g3aWj0qq9+b1XRS/LJN6Q5i+29eXOm0g5nFE2IWtOwelTR1 cqNQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:content-language :in-reply-to:mime-version:user-agent:date:message-id:from:references :cc:to:subject; bh=3Sv3brn07T7w/0ZVqJuBJjamEGkG5CPmpcsip+UiH+o=; b=mB7tmmRtk4tA88hOyqCw/kkrWaCz+tG5iKEldJiKjmbfwpwzN40lXGZ3UoJtZF8M2Q 8kXP3iBnezvmjojgxNxFSNsY/OqfDmvqxW2qVGrb4EDm9p2shBCsbW7ThPe7A8KbrlJH HmIafN1ORgSmGVQNgXHa1G4CJfVKk9D6StJYosjYQDFYmLKpL1fcFOrzyKkmTRz5Nhti /bo0gX1MNpN5+Qe1Ws3RPwzcQcO5v7HnT77wlPHyHyMIgFinPyKQbb0qN/RX01kD9fXF mw0dy8GmiNp4k3Sv+j+DqOQxSsZmb8OEtW5Nfxs+5HcdqBfEGhPk7msXafI0G3f3gBJ5 yEaQ== ARC-Authentication-Results: i=1; mx.google.com; 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 a22si5316333edx.443.2021.02.26.03.09.41; Fri, 26 Feb 2021 03:10:04 -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; 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 S230509AbhBZLI4 (ORCPT + 99 others); Fri, 26 Feb 2021 06:08:56 -0500 Received: from mx2.suse.de ([195.135.220.15]:47746 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230165AbhBZLIw (ORCPT ); Fri, 26 Feb 2021 06:08:52 -0500 X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.221.27]) by mx2.suse.de (Postfix) with ESMTP id 56765AF33; Fri, 26 Feb 2021 11:08:10 +0000 (UTC) Subject: Re: [PATCH v7 1/1] mm/page_alloc.c: refactor initialization of struct page for holes in memory layout To: Mike Rapoport Cc: Mike Rapoport , Andrew Morton , Andrea Arcangeli , Baoquan He , Borislav Petkov , Chris Wilson , David Hildenbrand , "H. Peter Anvin" , Ingo Molnar , Linus Torvalds , =?UTF-8?Q?=c5=81ukasz_Majczak?= , Mel Gorman , Michal Hocko , Qian Cai , "Sarvela, Tomi P" , Thomas Gleixner , linux-kernel@vger.kernel.org, linux-mm@kvack.org, stable@vger.kernel.org, x86@kernel.org References: <20210224153950.20789-1-rppt@kernel.org> <20210224153950.20789-2-rppt@kernel.org> <20210225180521.GH1854360@linux.ibm.com> <20210226105900.GK1854360@linux.ibm.com> From: Vlastimil Babka Message-ID: Date: Fri, 26 Feb 2021 12:08:09 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.7.1 MIME-Version: 1.0 In-Reply-To: <20210226105900.GK1854360@linux.ibm.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 2/26/21 11:59 AM, Mike Rapoport wrote: > On Thu, Feb 25, 2021 at 07:38:44PM +0100, Vlastimil Babka wrote: >> On 2/25/21 7:05 PM, Mike Rapoport wrote: >> >> >> >> What if two zones are adjacent? I.e. if the hole was at a boundary between two >> >> zones. >> > >> > What do you mean by "adjacent zones"? If there is a hole near the zone >> > boundary, zone span would be clamped to exclude the hole. >> >> Yeah, zone span should exclude those pages, but you still somehow handle them? >> That's how I read "pages that are not spanned by any node will get links to the >> adjacent zone/node." >> So is it always a unique zone/node can be determined? >> >> Let's say we have: >> >> >> ---- pageblock boundary ---- >> >> >> >> ---- pageblock boundary ---- >> >> Now I hope such configurations don't really exist :) But if we simulated them in >> QEMU, what would be the linkage in struct pages in that hole? > > I don't think such configuration is possible in practice but it can be > forced with e.g memmap="2M hole at 4G - 1M". Right. > The hole in your example the hole will get node1 for node and zone that > spans the beginning of node1 for zone. Yeah the comments in v8 make that clear now, thanks!