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=-7.8 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,NICE_REPLY_A,SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_1 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 15874C433E0 for ; Tue, 5 Jan 2021 09:37:48 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 89D3022482 for ; Tue, 5 Jan 2021 09:37:47 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 89D3022482 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=redhat.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id F0F9B8D0077; Tue, 5 Jan 2021 04:37:46 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id EC0108D006E; Tue, 5 Jan 2021 04:37:46 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id D62408D0077; Tue, 5 Jan 2021 04:37:46 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0085.hostedemail.com [216.40.44.85]) by kanga.kvack.org (Postfix) with ESMTP id BEA0E8D006E for ; Tue, 5 Jan 2021 04:37:46 -0500 (EST) Received: from smtpin01.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay01.hostedemail.com (Postfix) with ESMTP id 7B525180AD80F for ; Tue, 5 Jan 2021 09:37:46 +0000 (UTC) X-FDA: 77671219332.01.trade12_53153f6274d7 Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin01.hostedemail.com (Postfix) with ESMTP id 535D01004D436 for ; Tue, 5 Jan 2021 09:37:46 +0000 (UTC) X-HE-Tag: trade12_53153f6274d7 X-Filterd-Recvd-Size: 3617 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [216.205.24.124]) by imf27.hostedemail.com (Postfix) with ESMTP for ; Tue, 5 Jan 2021 09:37:45 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1609839465; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=JB+GylXXOsFZLBr2+X54dETYWqMoYOjPzlJVxocFmj4=; b=N/zkv1XbSTf5w2w+y2BDM8qrSS+G4Zs+JTOMZIpVvySmGzp1+7RhnRsVN8hEIsyEdBG7Sf mSNZNyhPv19p2+GfNKnbnRmV81XozEfJGa4d/VW+eBPikwGYR/Uj2W44SBGtQGNKvQuPtN IpPkJZLhkWJlCJwQkd3gdAqXHlCqub4= Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-501-kFtvb3y5P3arydwG1Nq_Jw-1; Tue, 05 Jan 2021 04:37:41 -0500 X-MC-Unique: kFtvb3y5P3arydwG1Nq_Jw-1 Received: from smtp.corp.redhat.com (int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 5B1821966320; Tue, 5 Jan 2021 09:37:40 +0000 (UTC) Received: from [10.36.114.117] (ovpn-114-117.ams2.redhat.com [10.36.114.117]) by smtp.corp.redhat.com (Postfix) with ESMTP id 7A3A9722C1; Tue, 5 Jan 2021 09:37:39 +0000 (UTC) Subject: Re: uninitialized pmem struct pages To: Dan Williams Cc: Michal Hocko , Linux MM , LKML References: <20210104100323.GC13207@dhcp22.suse.cz> <033e1cd6-9762-5de6-3e88-47d3038fda7f@redhat.com> From: David Hildenbrand Organization: Red Hat GmbH Message-ID: Date: Tue, 5 Jan 2021 10:37:38 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.5.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.79 on 10.5.11.11 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: >> Yeah, obviously the first one. Being able to add+use PMEM is more >> important than using each and every last MB of main memory. >> >> I wonder if we can just stop adding any system RAM like >> >> [ Memory Section ] >> [ RAM ] [ Hole ] >> >> When there could be the possibility that the hole might actually be >> PMEM. (e.g., with CONFIG_ZONE_DEVICE and it being the last section in a >> sequence of sections, not just a tiny hole) > > I like the simplicity of it... I worry that the capacity loss > regression is easy to notice by looking at the output of free(1) from > one kernel to the next and someone screams. Well, you can always make it configurable and then simply fail to add PMEM later if impossible (trying to sub-section hot-add into early section). It's in the hands of the sysadmin then ("max out system ram" vs. "support any PMEM device that could eventually be there at runtime"). Distros would go for the second. I agree that it's not optimal, but sometimes simplicity has to win. -- Thanks, David / dhildenb