Received: by 2002:ac0:a5a6:0:0:0:0:0 with SMTP id m35-v6csp4306368imm; Tue, 11 Sep 2018 09:52:54 -0700 (PDT) X-Google-Smtp-Source: ANB0VdZiq2UFhjSeM1BFwj4q4/A3U5ermvOQ+HXw0Y7MYtV4RX+8QL2eQR3quh4lSPEar3IGjewH X-Received: by 2002:a17:902:934a:: with SMTP id g10-v6mr27998167plp.121.1536684774032; Tue, 11 Sep 2018 09:52:54 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1536684774; cv=none; d=google.com; s=arc-20160816; b=vbAosdU2OJukjJXqU/Eo0/7HOSmpIazZoo/0BTIE8LFFFyhDuvxs/pF46wEn4W4EGZ hUT9KjFDMdPRRz2ypsKi6qXAPtJpbjzAdlTLSyCiPrJUo896uGniQVah7aA/QZN0Bltj rLelachZDnkAt+EIzBzax5ChQ8zfxS5ItJjJw9do+BzIUtjH7uyt41XvHzh55L26SUsw iLDh/8L60w1ItVSt4TClV8iQpAyTHnuUyRGEnA3ByStBUE3Ui980gsH245Ub33EAtTB0 dX0EZ5fEBhlAkEpc8E9gSb08EiiJbUysCHhLorpZX72gSeEu8F0p8ughjIs6l56UJOal tU9w== 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 :references:in-reply-to:mime-version:dkim-signature; bh=lNj2SyibD2/ZFnLTJC7LDZoFwwKQA0POEalo9I1Io9U=; b=C+vmIPspIY5wv5+wvq5JuqfFuAWZdxjMGJdDD9kQX5yLIAtsDC0J/79QaX3Ef5zFPD r1GnDSEXwi6CYg3vdYSdRC3ncW8d0LOH4+95b7rYowL91MW9YtjovBGSPgF1ZeyVJPAz O7q8HYbx+tFtjrlVh0LGF4z6HR1Rl/+2EQeUhmUxjM3H3+abNHpJMcXSm14y9dNCdXIT t0e5F7oOXAb9b+OVq0keKQS3sA1jllUtbs1pwP9EBwt9jP+1t9B7LMAf7UGbkr9GU/F4 ABj1lBHSPu5uwEBDZyJNiFr3HRYP0+0UuzJVJVCDTXF7uNW04OBCgr6LL1ftG8eJ1DHD A+nQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@intel-com.20150623.gappssmtp.com header.s=20150623 header.b=GPQn9khJ; 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=fail (p=NONE sp=NONE dis=NONE) header.from=intel.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id v38-v6si22308737plg.179.2018.09.11.09.52.38; Tue, 11 Sep 2018 09:52:53 -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=@intel-com.20150623.gappssmtp.com header.s=20150623 header.b=GPQn9khJ; 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=fail (p=NONE sp=NONE dis=NONE) header.from=intel.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728041AbeIKVvJ (ORCPT + 99 others); Tue, 11 Sep 2018 17:51:09 -0400 Received: from mail-oi0-f66.google.com ([209.85.218.66]:37728 "EHLO mail-oi0-f66.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727164AbeIKVvI (ORCPT ); Tue, 11 Sep 2018 17:51:08 -0400 Received: by mail-oi0-f66.google.com with SMTP id p84-v6so48508189oic.4 for ; Tue, 11 Sep 2018 09:50:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=intel-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=lNj2SyibD2/ZFnLTJC7LDZoFwwKQA0POEalo9I1Io9U=; b=GPQn9khJsjfrDJGAnVbxcuxKwrFyYXG2d/aAYh6/S8Iaxt4Ws1i/E6da3gvSM0fCsY FsNiJhxmQySNLMwVBgDrfkbFJSzBNf7g37MvV/eIkQ0GvyLYg7mml4Hvp+Uv8df2DJkg fSg/axfsrneP99SD5xybI0vtG7sNatA35mjskE1mK7J4g/qvrBJC7TXlimln/9wsxgSY Hua68AqTOo0Afu6QXqL1i0aH/BVIiB1R+i6gcgoj2EtD6WHrjGaQeRCnZ6O/2JS984IS CcvA60AjWHtR8eVxxWar/f78mXNNs+2gqcmTdgt5j7ibyoZ27hh4jMERFG3oVbcyz+87 4FoA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=lNj2SyibD2/ZFnLTJC7LDZoFwwKQA0POEalo9I1Io9U=; b=n1WgJF07tf8YsmsXBIo1MI6gjqQl8a+dhvx8Z4xRSCeciwguylaCfd/3z04SguRnFR j/saodeCCQjpDGfZz1gPVMsT/tegwn68NoHktAmHcXRfbZTdEOUGTHFkqz31t0HeHSep Joufu0lXFlAUFamgnFuIbDK9tu5QUQf8A3rEcduyLJEzcjLoJ79mE4RsJGC6xu8UGk/q vBk0vdlkGb64oT5rbXoBiDhz0rYEHpWolfOjd3wDRnc3sGkvMBdo00spgAqGxDm0YrXR k6ZNokQHiOM1RuDN/HjMSUQ1HioHLBn6LZyc5e7zQEbdB4t6UHHmmV1ZH/W5NksKYJTL IzZg== X-Gm-Message-State: APzg51DzlbF1hO0sSJuXSXfxaocw9uBRh0/XM8ViDxXJD8oW6I8TX4Uy JSypBazD/2YuOFNDgIY2s0yNQjAFrEjPIBYZ4XpImQ== X-Received: by 2002:aca:4914:: with SMTP id w20-v6mr30209869oia.5.1536684658387; Tue, 11 Sep 2018 09:50:58 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a4a:8e85:0:0:0:0:0 with HTTP; Tue, 11 Sep 2018 09:50:57 -0700 (PDT) In-Reply-To: <20180910234341.4068.26882.stgit@localhost.localdomain> References: <20180910232615.4068.29155.stgit@localhost.localdomain> <20180910234341.4068.26882.stgit@localhost.localdomain> From: Dan Williams Date: Tue, 11 Sep 2018 09:50:57 -0700 Message-ID: Subject: Re: [PATCH 1/4] mm: Provide kernel parameter to allow disabling page init poisoning To: Alexander Duyck Cc: Linux MM , Linux Kernel Mailing List , linux-nvdimm , pavel.tatashin@microsoft.com, Michal Hocko , Dave Jiang , Ingo Molnar , Dave Hansen , =?UTF-8?B?SsOpcsO0bWUgR2xpc3Nl?= , Andrew Morton , Logan Gunthorpe , "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 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.