Received: by 2002:a05:6902:102b:0:0:0:0 with SMTP id x11csp161651ybt; Tue, 23 Jun 2020 18:14:46 -0700 (PDT) X-Google-Smtp-Source: ABdhPJzZdQ3GcTl7uTiFBz3Lcy1qA8F/TrBrRQ0l6iOmAD86oDGZfG8f10Ends+OnkBvPSQOJMUe X-Received: by 2002:a50:f009:: with SMTP id r9mr4157340edl.72.1592961286253; Tue, 23 Jun 2020 18:14:46 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1592961286; cv=none; d=google.com; s=arc-20160816; b=DRtUu5CWZNwQN0TkhyVZoiXLq1e6vHoHuYNBcWadotx069uFy5RhkarvuRR0Xs5APD sGMNPkJZe5eWBhSZPyh5rcOpticHWatLQ2CzoVRGZYfO640uPL5PdS1iH1VXkREj+uhv clp6wg/tddkAU6NgYcmayi0cB6eHjejG8XUXM0oT6DSycuNsrMLglftNyHSiw6SET1XW tAgmC9m+RU32AVA+rAGCwuI86XT7QwvafOeTht1BR5Iw6lnK5AXAkVV5cOaZwHCq66xh y7+tK8ri/e7VeKttLCd1fqMxNdXNLgL9W7WvorDP5rAL+RFiQSTSoeEZBI0uHvkTKJmv A+2Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:in-reply-to:content-disposition :mime-version:references:reply-to:message-id:subject:cc:to:from:date; bh=V993VOw3gzD5JHaI6JsWXXS0r8FUsnSBxeSbR6Y98uI=; b=IhxWJqlTV2AOrANLCoMdyhJsxuXhf1vuFCEu4kkMvQtf03D6I9B8kSv6BxycrOn6MK m8TJJJhfErYLgP4sEIGaoy5p7WrYJwTmv2gl1UwkfnmDYHA9qxJeuLXYHYCP2EHPQ7tR vxNK/mOJrWNtQFpMb15mPNJEJMtUwH1Zy3Xnuxf164d3ZGq3ZanxFTUJUl0wSo5SOZC6 1DiKCQeqef4J42dno1m5JyHI+0n5TUAgU7j4/FHy2cz0oNDd+kfSGu8yw8oClHkbw96o r9BiPLWk6obsMrG4AKAfTbMdaNAcD0RYyykT0Zis+iI3VVT+UnjFLJszNBk/tKq/uAKC hHGA== 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; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=alibaba.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id y1si5255554edt.101.2020.06.23.18.14.21; Tue, 23 Jun 2020 18:14:46 -0700 (PDT) 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; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=alibaba.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2388240AbgFXBLW (ORCPT + 99 others); Tue, 23 Jun 2020 21:11:22 -0400 Received: from out30-132.freemail.mail.aliyun.com ([115.124.30.132]:49766 "EHLO out30-132.freemail.mail.aliyun.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2387916AbgFXBLW (ORCPT ); Tue, 23 Jun 2020 21:11:22 -0400 X-Alimail-AntiSpam: AC=PASS;BC=-1|-1;BR=01201311R341e4;CH=green;DM=||false|;DS=||;FP=0|-1|-1|-1|0|-1|-1|-1;HT=e01e01419;MF=richard.weiyang@linux.alibaba.com;NM=1;PH=DS;RN=7;SR=0;TI=SMTPD_---0U0Xwint_1592961078; Received: from localhost(mailfrom:richard.weiyang@linux.alibaba.com fp:SMTPD_---0U0Xwint_1592961078) by smtp.aliyun-inc.com(127.0.0.1); Wed, 24 Jun 2020 09:11:18 +0800 Date: Wed, 24 Jun 2020 09:11:18 +0800 From: Wei Yang To: Dan Williams Cc: Wei Yang , Andrew Morton , Oscar Salvador , Linux MM , Linux Kernel Mailing List , David Hildenbrand Subject: Re: [PATCH] mm/spase: never partially remove memmap for early section Message-ID: <20200624011118.GA9422@L-31X9LVDL-1304.local> Reply-To: Wei Yang References: <20200623094258.6705-1-richard.weiyang@linux.alibaba.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Jun 23, 2020 at 05:21:06PM -0700, Dan Williams wrote: >On Tue, Jun 23, 2020 at 2:43 AM Wei Yang > wrote: >> >> For early sections, we assumes its memmap will never be partially >> removed. But current behavior breaks this. > >Where do we assume that? > >The primary use case for this was mapping pmem that collides with >System-RAM in the same 128MB section. That collision will certainly be >depopulated on-demand depending on the state of the pmem device. So, >I'm not understanding the problem or the benefit of this change. Hi, Dan There is a discussion in the thread you just replied: mm/shuffle: don't move pages between zones and don't read garbage memmaps Besides this, the comment in section_activate() says: * The early init code does not consider partially populated * initial sections, it simply assumes that memory will never be * referenced. If we hot-add memory into such a section then we * do not need to populate the memmap and can simply reuse what * is already there. Per my understanding, if we hot-add then hot-remove the sub-section, we may not have a valid memmep for this part sub-section? Because we depopulate it at hot-remove while we don't populate it when hot-add. Is my understanding correct? -- Wei Yang Help you, Help me