Received: by 2002:a05:6902:102b:0:0:0:0 with SMTP id x11csp938970ybt; Wed, 24 Jun 2020 15:22:12 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwa3Os/2X0z4GpxufZnquG8HTWoGSpKQMv0nT36n6AJCtIh2naiKziAYJrd+r0+kYsoypED X-Received: by 2002:a05:6402:c09:: with SMTP id co9mr28278957edb.238.1593037332305; Wed, 24 Jun 2020 15:22:12 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1593037332; cv=none; d=google.com; s=arc-20160816; b=hj0pVr5Onj8it5adQAPaUWsuHeRXFtVdZZo1Y0u1QhycY+O4Tm50Hi3D1jb/tSGLoH iEa9HpvDM08Pisy7sONlt1emzuqo5xT7c+5noxDBJY11XGu0YAh7/3ygThd+//sa93PM o19Gua9tjSnXuYd+2svETIekaPtNhzi+zE+Ptmu9WnZYQ3izBQXzwjNNU4R73sMVe0G8 XCce38smOVu3d4CzwuoRwEuP6X95YhJwOMZwNFn6UROY9G+tnHMK2KuhtOr04KW3Ryap xhoAlv37Yr3CUW2QSY/5hdLuczokH02nqQwb0gUDqpKEAEtFcRYoJJaB42a/oOheOfjW +o8Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:dkim-signature; bh=oC+NYQSkrU/82u5pefwOvMnMpYXJEhra5n0Gd74+VNk=; b=dLvB0vYCdl7ppIDM02W/3o2r4Q29IfTrhxrhWuXA/BfK16CO6U0r2rEHPy7HR0UJfi RxTdUCDH19h5QSM5EghsZIT9+zGdz3OiSMoCwLNfssS9XsD4aXgCcuc6W80E8n5GC3ez YzED7VWVqnwyiIDmNRIfKikLwOAxNxXuwEKWUlExhHOgJdx/If/1AxlIS+7u/zMXnG4u 1J2fp5FqcbRVQBTZ63NtruZ904zdx8q7ysvlrGhOcMLY4FEyZtx4OBgGdQA3t/7SRr5N 3qwDYlx+EK5hwcr0oWVRQVcLBKSRT0WnacDRp990RejeTkUc8TNtyEtyIK/sWITun0Ko A76Q== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@intel-com.20150623.gappssmtp.com header.s=20150623 header.b=cfiXxz18; 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=intel.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id o13si14526679edv.186.2020.06.24.15.21.49; Wed, 24 Jun 2020 15:22:12 -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; dkim=pass header.i=@intel-com.20150623.gappssmtp.com header.s=20150623 header.b=cfiXxz18; 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=intel.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2389153AbgFXWVM (ORCPT + 99 others); Wed, 24 Jun 2020 18:21:12 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:39184 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728798AbgFXWVL (ORCPT ); Wed, 24 Jun 2020 18:21:11 -0400 Received: from mail-ed1-x542.google.com (mail-ed1-x542.google.com [IPv6:2a00:1450:4864:20::542]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 6DB5AC061573 for ; Wed, 24 Jun 2020 15:21:11 -0700 (PDT) Received: by mail-ed1-x542.google.com with SMTP id d15so2654305edm.10 for ; Wed, 24 Jun 2020 15:21:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=intel-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=oC+NYQSkrU/82u5pefwOvMnMpYXJEhra5n0Gd74+VNk=; b=cfiXxz18UcsUTtVYkPxudOrKjkJS3D/mypjmZqYytbt9vncI2FXTSlS91xmOg2/noq K7aCdTDolXEdHYwtYlWGG/ksuTbpfrhn6hcoGxTR82oQg5YVMHGycPcewwrPZmBVGnOT FAO1owuI463UjQxq2o4Wtr+UTo6ccMNxp4s4ok4omAPcpGqVnx02uhvcZvp/OgbQuvxl gIVJzA5UfssFUGx4/PAFLu3Yzp1Xkd8EBFYCx8q7605czBMdzklNgeBIoYeTBkFfdt3d 0o0aTNHwdbE+6dQZyiaQ7KQd3Z+2eYz6p8hBJT9Xr/+W+gZSM6Nz9rSohUj/THUpNsJT 2cgg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=oC+NYQSkrU/82u5pefwOvMnMpYXJEhra5n0Gd74+VNk=; b=E6AYfPDI+h7I0iqtTJRyFgjJS8PrGcDR9oiCIoOE9UUhfb8h0luGLBzQtyN/mGYAhT 9XRzkYQMQIHskzu/voR83idojfxqxvRJRQ9CIs//dQhuHdhow1tHHk50p90GcE8dOKsS G4j6XCmBWlVAAyGBKkH1UEXz3M2iozm2KiH4cXh++OykKQpWsezOxNsuQP4c8W4/VoMc q2qBjjNlcKOXpByKdeBuEguzSXy5eSloYvIWIfi3RDZknq0z0bmAQ6PMrNjAlK+k7cdA e9geg4KnClZcxFG7EKR9G0cR1YTgUYrn9eOtZAyZX987pv9ZIBKsFNE7Ove99tljpO0o D4MA== X-Gm-Message-State: AOAM531dOalb5XU/1FYfNp+/wf2vkWIwdL+S0iHdbU2qGJHbbST5+AMW DBqfICRcxU5/TL3+KBjcPVR5nwphSyqpZCu6jrETFw== X-Received: by 2002:a05:6402:21c2:: with SMTP id bi2mr28750955edb.296.1593037270081; Wed, 24 Jun 2020 15:21:10 -0700 (PDT) MIME-Version: 1.0 References: <20200623094258.6705-1-richard.weiyang@linux.alibaba.com> <20200623151828.GA31426@dhcp22.suse.cz> <20200624061340.GA11552@L-31X9LVDL-1304.local> <20200624220552.GA15016@L-31X9LVDL-1304.local> In-Reply-To: <20200624220552.GA15016@L-31X9LVDL-1304.local> From: Dan Williams Date: Wed, 24 Jun 2020 15:20:59 -0700 Message-ID: Subject: Re: [PATCH] mm/spase: never partially remove memmap for early section To: Wei Yang Cc: Michal Hocko , Andrew Morton , Oscar Salvador , Linux MM , Baoquan He , Linux Kernel Mailing List , David Hildenbrand Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Jun 24, 2020 at 3:06 PM Wei Yang wrote: > > On Wed, Jun 24, 2020 at 09:10:09AM -0700, Dan Williams wrote: > >On Tue, Jun 23, 2020 at 11:14 PM Wei Yang > > wrote: > >> > >> On Tue, Jun 23, 2020 at 05:18:28PM +0200, Michal Hocko wrote: > >> >On Tue 23-06-20 17:42:58, Wei Yang wrote: > >> >> For early sections, we assumes its memmap will never be partially > >> >> removed. But current behavior breaks this. > >> >> > >> >> Let's correct it. > >> >> > >> >> Fixes: ba72b4c8cf60 ("mm/sparsemem: support sub-section hotplug") > >> >> Signed-off-by: Wei Yang > >> > > >> >Can a user trigger this or is this a theoretical bug? > >> > >> Let me rewrite the changelog a little. Look forward any comments. > >> > >> For early sections, its memmap is handled specially even sub-section is > >> enabled. The memmap could only be populated as a whole. > >> > >> Quoted from the comment of section_activate(): > >> > >> * 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. > >> > >> While current section_deactivate() breaks this rule. When hot-remove a > >> sub-section, section_deactivate() would depopulate its memmap. The > >> consequence is if we hot-add this subsection again, its memmap never get > >> proper populated. > > > >Ok, forgive the latency as re-fetched this logic into my mental cache. > >So what I was remembering was the initial state of the code that > >special cased early sections, and that still seems to be the case in > >pfn_valid(). IIRC early_sections / bootmem are blocked from being > >removed entirely. Partial / subsection removals are ok. > > Would you mind giving more words? Partial subsection removal is ok, so no need > to fix this? Early sections establish a memmap for the full section. There's conceptually nothing wrong with unplugging the non-system-RAM portion of the memmap, but it would need to be careful, at least on x86, to map the partial section with PTEs instead of PMDs. So, you are right that there is a mismatch here, but I think the comprehensive fix is to allow early sections to be partially depopulated/repopulated rather than have section_activate() and section_deacticate() special case early sections. The special casing is problematic in retrospect as section_deactivate() can't be maintained without understand special rules in section_activate().