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=-4.0 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SIGNED_OFF_BY,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 62F1CC433DF for ; Wed, 24 Jun 2020 22:21:13 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 211E02076E for ; Wed, 24 Jun 2020 22:21:13 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=intel-com.20150623.gappssmtp.com header.i=@intel-com.20150623.gappssmtp.com header.b="cfiXxz18" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 211E02076E Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=intel.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id AB1E46B0002; Wed, 24 Jun 2020 18:21:12 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id A626C6B0003; Wed, 24 Jun 2020 18:21:12 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 99F736B0005; Wed, 24 Jun 2020 18:21:12 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0200.hostedemail.com [216.40.44.200]) by kanga.kvack.org (Postfix) with ESMTP id 814D96B0002 for ; Wed, 24 Jun 2020 18:21:12 -0400 (EDT) Received: from smtpin28.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay05.hostedemail.com (Postfix) with ESMTP id 3D757181ABE87 for ; Wed, 24 Jun 2020 22:21:12 +0000 (UTC) X-FDA: 76965527184.28.smash22_140becb26e47 Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin28.hostedemail.com (Postfix) with ESMTP id 1B7196D63 for ; Wed, 24 Jun 2020 22:21:12 +0000 (UTC) X-HE-Tag: smash22_140becb26e47 X-Filterd-Recvd-Size: 5808 Received: from mail-ed1-f67.google.com (mail-ed1-f67.google.com [209.85.208.67]) by imf50.hostedemail.com (Postfix) with ESMTP for ; Wed, 24 Jun 2020 22:21:11 +0000 (UTC) Received: by mail-ed1-f67.google.com with SMTP id e22so2653363edq.8 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=aRw44t+ANk6RTKNHK5XSxI89/oPBGBAQNHdH4yNw3Qv8QrWHZZN5zVsio+OubluQpV uyFNqR/fCbmwTmm+EPAD+3qVg7zpPCJpH4TmgvK4EoMBPeBqpiTC/c9Wdkrd08AJvrmk 5aeVsMqVfQFO/jn6XP9hLqU0f3UcmKTR5ZWIB4lhW/c0fHGrdwBXt6qxGSsugZ1K7qPE fEB4Z7mD/o71HrABGZWzTU4tqnkav853FOTwoPRnUHsmu2lhYUgJss4VZAJFN9/TFA0l hMGqtZfIJPCVkMfkIgKo11CMOsIbllcZIcZL5dr206kGCrW+rU0dvyWpdwV4iaiKBpZN jV4A== X-Gm-Message-State: AOAM532LneFmdou7xck6BNGq1GxpriDU1RsRnEXxqtaspc51t4gQFlgi lsblnAUMbLfa+OpQBqQ1vXKSGO6p1JE8wCeXzMfNmA== X-Google-Smtp-Source: ABdhPJwkiTjqv/XIlHUqP0Lo2kCyx8fwyWb01W72Bo9PErcyKDCrN1JTm81ExY2Pc/Gcfzgj5uNopA9koNiNuXA35yI= 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" X-Rspamd-Queue-Id: 1B7196D63 X-Spamd-Result: default: False [0.00 / 100.00] X-Rspamd-Server: rspam04 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, 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().