Received: by 2002:ac0:a5a6:0:0:0:0:0 with SMTP id m35-v6csp4508221imm; Tue, 11 Sep 2018 13:02:12 -0700 (PDT) X-Google-Smtp-Source: ANB0VdbSAKftq/YTU0DlcYtwHuNcF3hpS6ww36DFAZ+v5qTIUJqDdmZ9YbIf32I5bXeLyL25PIUG X-Received: by 2002:a62:5302:: with SMTP id h2-v6mr31634356pfb.183.1536696132641; Tue, 11 Sep 2018 13:02:12 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1536696132; cv=none; d=google.com; s=arc-20160816; b=j6fKEAqHgkdz/nXS0nSttTc+8NZyEbchaDuGafn+UViWgqirFX+edw8aIMu79pz8ls e/nL/sSc235brWKGW3dZ9KXcCaHDUj5EKmnZKUBIQPXfqjxSod8GCDs2BRiaO1mN2NsC fR14/30i0aHxCAjsLuclCvF29jLqPf5C73d2UG6j73lUpX2iErjxG73qj3aZ3nfPhoMX qbCtJVrCN8y07+0DBTNqGqI00236FOPBSPzkbiZzkuCGzpUY9AESEh2dcwMlJwJwmh1T UAJ4uy7hhLQrzaTCORwMWxkbvuoQrYn7C9jiVotAkaUE+eUwBe5agnBey8JzAUylSP8N QZ9g== 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=tY3hAzyua46qM88cex1j7mbhN+b7279JkNfKSpk0DNY=; b=HcvH5By0Tt0BDG+KZZLsQz0nr/CR+1hiWGc+lULGOC5QZ88x2HlopLPA9khr+GqTAY 5YUsmjRRC1/sywYjzGAx4efmArSnhcaqENp+IXk6xxgOaeHuJVyyQfRfxXXcbl5mKnrt 1FtwxbURpNPBJEvIChg9FrcJE5zb0eIWNtUMKbuDFm6HDVmCMZOet1S/vHC1mlMBxfZk hT0QTc9o5052B61H/y60MfqPYWvvhEWSjr8jIqwQ97hAct2ks/laFON1xdukjhLeLXjO moc3DixjYtsoGWbxR2rhzXSp6X4iw/gIe7EFTBvOt4EQkbPobLXvWrwtShm4GbYUkCc0 wZqg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=WQjm4Glb; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id u18-v6si21130000plq.1.2018.09.11.13.01.54; Tue, 11 Sep 2018 13:02:12 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=WQjm4Glb; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726850AbeILBCl (ORCPT + 99 others); Tue, 11 Sep 2018 21:02:41 -0400 Received: from mail-it0-f67.google.com ([209.85.214.67]:52760 "EHLO mail-it0-f67.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726720AbeILBCl (ORCPT ); Tue, 11 Sep 2018 21:02:41 -0400 Received: by mail-it0-f67.google.com with SMTP id h3-v6so3251078ita.2 for ; Tue, 11 Sep 2018 13:01:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=tY3hAzyua46qM88cex1j7mbhN+b7279JkNfKSpk0DNY=; b=WQjm4Glb3dQsPSMKm2ZxaOnwTnTlyfFHqp8jAxmASn1Je/4kL/YESZnji8OpgHlZCz yILX4x/TXbNj8WY/I+A0znXW7OfDsZUF57ZXQcAgqSNDxzlT3QfIs2QhDr7MopU61e93 UshdwxEY3oSkj45W/N8GtbBZoAEvt2USWP3Psir1ZDORO40wPZouzWfULu8xbq41G2YW 16+1Q4pqBrxMs5SnLo85ryPcb9pjti/ABpozEQ0oObDoYKWqYtpt9o9XA2Dn0nYwBQlC 34ubpM3OnKMbbRpRETlwSnFJX9e75DrygHUaw7yseagGXI6X9Tp8JsFKUFQo4iox7e9h qbPg== 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=tY3hAzyua46qM88cex1j7mbhN+b7279JkNfKSpk0DNY=; b=V/IFhZbdQlFkOEuV1Jyocif7Er3giQD3WoTBAnXA0sAhGeFyLNIlHsioF3Zn9F3aMI EWZYm7qGuQcEheMCU6iAMBW/X6ZqjjSwExfbbxws/zY3g2ztai5PsufM4GwWCcEU7o65 63p2r84J+vePBMoctiGKC+qQJDAnYlSPb9JMMxMiAzINrEDoYRyGnCDDlQUa/+wayK8R kJBLKi6AJMKLZkIIL4Rr7QZ1bAdda0Of2JDxLCtXlVOBKnJNxhOCnuiSRu4eoBH4mpJH cAgHWz/7hd+Zk1DIOGFk9Cud5fXmiUvrMXiGjW1D0NoT8YJEpmjweQ3w49losZGQlrs6 Xu9A== X-Gm-Message-State: APzg51ChsmFAncIKf2IMy7S4MJguxljFiVCdJrYD3wUq50KxLrpPI8jv qAuMpRIk/kY0bweCZQfmzeYbVSRGdu/Xy9NTuFo= X-Received: by 2002:a24:ed84:: with SMTP id r126-v6mr3276827ith.58.1536696108998; Tue, 11 Sep 2018 13:01:48 -0700 (PDT) MIME-Version: 1.0 References: <20180910232615.4068.29155.stgit@localhost.localdomain> <20180910234341.4068.26882.stgit@localhost.localdomain> In-Reply-To: From: Alexander Duyck Date: Tue, 11 Sep 2018 13:01:37 -0700 Message-ID: Subject: Re: [PATCH 1/4] mm: Provide kernel parameter to allow disabling page init poisoning To: dan.j.williams@intel.com Cc: linux-mm , LKML , linux-nvdimm@lists.01.org, pavel.tatashin@microsoft.com, Michal Hocko , dave.jiang@intel.com, Ingo Molnar , Dave Hansen , jglisse@redhat.com, Andrew Morton , logang@deltatee.com, "Kirill A. Shutemov" 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 Tue, Sep 11, 2018 at 9:50 AM Dan Williams wrote: > > On Mon, Sep 10, 2018 at 4:43 PM, Alexander Duyck > wrote: > > From: Alexander Duyck > > > > On systems with a large amount of memory it can take a significant amount > > of time to initialize all of the page structs with the PAGE_POISON_PATTERN > > value. I have seen it take over 2 minutes to initialize a system with > > over 12GB of RAM. > > > > In order to work around the issue I had to disable CONFIG_DEBUG_VM and then > > the boot time returned to something much more reasonable as the > > arch_add_memory call completed in milliseconds versus seconds. However in > > doing that I had to disable all of the other VM debugging on the system. > > > > In order to work around a kernel that might have CONFIG_DEBUG_VM enabled on > > a system that has a large amount of memory I have added a new kernel > > parameter named "page_init_poison" that can be set to "off" in order to > > disable it. > > In anticipation of potentially more DEBUG_VM options wanting runtime > control I'd propose creating a new "vm_debug=" option for this modeled > after "slub_debug=" along with a CONFIG_DEBUG_VM_ON to turn on all > options. > > That way there is more differentiation for debug cases like this that > have significant performance impact when enabled. > > CONFIG_DEBUG_VM leaves optional debug capabilities disabled by default > unless CONFIG_DEBUG_VM_ON is also set. Based on earlier discussions I would assume that CONFIG_DEBUG_VM would imply CONFIG_DEBUG_VM_ON anyway since we don't want most of these disabled by default. In my mind we should be looking at a selective "vm_debug_disable=" instead of something that would be turning on features. - Alex