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=-5.8 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS 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 AEAF5C433C1 for ; Wed, 24 Mar 2021 16:04:35 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 1D2BC61A09 for ; Wed, 24 Mar 2021 16:04:35 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 1D2BC61A09 Authentication-Results: mail.kernel.org; dmarc=fail (p=quarantine dis=none) header.from=suse.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 9F3836B02B7; Wed, 24 Mar 2021 12:04:34 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 9CA886B02BA; Wed, 24 Mar 2021 12:04:34 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 8926F6B02C0; Wed, 24 Mar 2021 12:04:34 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0102.hostedemail.com [216.40.44.102]) by kanga.kvack.org (Postfix) with ESMTP id 700156B02B7 for ; Wed, 24 Mar 2021 12:04:34 -0400 (EDT) Received: from smtpin16.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay05.hostedemail.com (Postfix) with ESMTP id 267951802BAB2 for ; Wed, 24 Mar 2021 16:04:34 +0000 (UTC) X-FDA: 77955240468.16.8EA372E Received: from mx2.suse.de (mx2.suse.de [195.135.220.15]) by imf03.hostedemail.com (Postfix) with ESMTP id B9FBBC001C4D for ; Wed, 24 Mar 2021 16:04:27 +0000 (UTC) X-Virus-Scanned: by amavisd-new at test-mx.suse.de DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1; t=1616601865; h=from:from:reply-to: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=V9iPv8fbewkZMzGZxeZestui1eX3Pr0sLFCxpSUHIGA=; b=SzXzWY6VpAKj6d9RwukPRmT/120eOmJvA7d+Ytlr7a8IQCgTXoYZ/Gtltj0JQADg/SHYQs ugIWvf8CnRwu+oO3mDrG44qvXGveUg5BCjFL92i7rpiSuFfR7Xqpq8KKGwv3f15c0RcHFq k+npGZqwYbZKkVHbQYhBtAeCOg5XZ44= Received: from relay2.suse.de (unknown [195.135.221.27]) by mx2.suse.de (Postfix) with ESMTP id 8CABDAD80; Wed, 24 Mar 2021 16:04:25 +0000 (UTC) Date: Wed, 24 Mar 2021 17:04:24 +0100 From: Michal Hocko To: David Hildenbrand Cc: Oscar Salvador , Andrew Morton , Anshuman Khandual , Vlastimil Babka , Pavel Tatashin , linux-mm@kvack.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH v5 1/5] mm,memory_hotplug: Allocate memmap from the added memory range Message-ID: References: <20210319092635.6214-1-osalvador@suse.de> <20210319092635.6214-2-osalvador@suse.de> <20210324101259.GB16560@linux> <3bc4168c-fd31-0c9a-44ac-88e25d524eef@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3bc4168c-fd31-0c9a-44ac-88e25d524eef@redhat.com> X-Rspamd-Server: rspam03 X-Rspamd-Queue-Id: B9FBBC001C4D X-Stat-Signature: 9uwsp5gqoa1qdfwuzgpii7gfq584xwii Received-SPF: none (suse.com>: No applicable sender policy available) receiver=imf03; identity=mailfrom; envelope-from=""; helo=mx2.suse.de; client-ip=195.135.220.15 X-HE-DKIM-Result: pass/pass X-HE-Tag: 1616601867-682464 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 24-03-21 15:52:38, David Hildenbrand wrote: > On 24.03.21 15:42, Michal Hocko wrote: > > On Wed 24-03-21 13:03:29, Michal Hocko wrote: > > > On Wed 24-03-21 11:12:59, Oscar Salvador wrote: > > [...] > > > > I kind of understand to be reluctant to use vmemmap_pages terminology here, but > > > > unfortunately we need to know about it. > > > > We could rename nr_vmemmap_pages to offset_buddy_pages or something like that. > > > > > > I am not convinced. It seems you are justr trying to graft the new > > > functionality in. But I still believe that {on,off}lining shouldn't care > > > about where their vmemmaps come from at all. It should be a > > > responsibility of the code which reserves that space to compansate for > > > accounting. Otherwise we will end up with a hard to maintain code > > > because expectations would be spread at way too many places. Not to > > > mention different pfns that the code should care about. > > > > The below is a quick hack on top of this patch to illustrate my > > thinking. I have dug out all the vmemmap pieces out of the > > {on,off}lining and hooked all the accounting when the space is reserved. > > This just compiles without any deeper look so there are likely some > > minor problems but I haven't really encountered any major problems or > > hacks to introduce into the code. The separation seems to be possible. > > The diffstat also looks promising. Am I missing something fundamental in > > this? > > > > From a quick glimpse, this touches on two things discussed in the past: > > 1. If the underlying memory block is offline, all sections are offline. Zone > shrinking code will happily skip over the vmemmap pages and you can end up > with out-of-zone pages assigned to the zone. Can happen in corner cases. You are right. But do we really care? Those pages should be of no interest to anybody iterating through zones/nodes anyway. > There is no way to know that the memmap of these pages was initialized and > is of value. > > 2. You heavily fragment zone layout although you might end up with > consecutive zones (e.g., online all hotplugged memory movable) What would be consequences? -- Michal Hocko SUSE Labs