Received: by 2002:ac0:a5a6:0:0:0:0:0 with SMTP id m35-v6csp5518454imm; Wed, 12 Sep 2018 07:11:30 -0700 (PDT) X-Google-Smtp-Source: ANB0Vdb9xV5tFniwzlWgLQuW1s6jhoJRlgnmpmI5DKmVXC2GEGnz5YEcgGRjb+EJb5beRty7mAiw X-Received: by 2002:a62:d085:: with SMTP id p127-v6mr2570686pfg.119.1536761490203; Wed, 12 Sep 2018 07:11:30 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1536761490; cv=none; d=google.com; s=arc-20160816; b=M32GsF4Fj5YwqsTfJujkmZhksGN2mMWdj4DLv7l8+P0Aeh10WIBpaU1439HpO788sq YIk/3PancqMAFfclBaRYBny6d6GduMWZpLKlDtoVlqeTsPEkJ6P9sDRwI3DJzw3RTntv IfQc9vYgeXANNDe6GATI9UZYf7XxgnnkShks7W09J3V/5NAp2+X5eIC3iwmuFXxNhm3J M/UKJk6bqkOGVqRz3LkQG+y9ZxcOF38hcIDv7CxXwAmzYDr5z8tSDm6lFlInJjJljGPL JUJ5MOjNP6nRaEKDF81TumgaVd8uDsMPu5JOyhTHjJ+VpaHZuxYR+WaFAXMlRrGT1Kk0 5Hhw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date; bh=XxxcrwV2dpTvQ9On9virAqXm1NLObIM20fCUEnteU2E=; b=ukUjQ2r8grBdti7uotejVtD6DM0xk9qAraWQn0ZU3moGKvxOjC6SZabEfAQB0yqnu1 TFrQ7ANkDPc6C80JHZbPL1XNa4ke0bP8jk8kVgJbNkv7svMe7Fx4YRdQmBwR1jccugdk yFvlhhxpFXGjYEJAyhNctFEcw9NKJXd0XDvZDQhxdvwlxIAjYI/l3iykFumJY0D0VR78 6WAvRp2n3youn1RmxQekQQbHmgfdlLwpPExtl49+yH5IdNVaxOB979htuDhQ4J8ruINP L3h5hOY30+kAwBs4MJT25eH/ggpQ0dV/CUgNKQiS7DtXx0t+PAbzUqhZUadI6bZRfDWM sNDA== ARC-Authentication-Results: i=1; mx.google.com; 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=kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id y27-v6si1217524pgl.479.2018.09.12.07.11.10; Wed, 12 Sep 2018 07:11:30 -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; 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=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727773AbeILTPi (ORCPT + 99 others); Wed, 12 Sep 2018 15:15:38 -0400 Received: from mx2.suse.de ([195.135.220.15]:42228 "EHLO mx1.suse.de" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1726642AbeILTPi (ORCPT ); Wed, 12 Sep 2018 15:15:38 -0400 X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.220.254]) by mx1.suse.de (Postfix) with ESMTP id 71AC4AEF2; Wed, 12 Sep 2018 14:10:55 +0000 (UTC) Date: Wed, 12 Sep 2018 16:10:53 +0200 From: Michal Hocko To: Alexander Duyck Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org, linux-nvdimm@lists.01.org, pavel.tatashin@microsoft.com, dave.jiang@intel.com, mingo@kernel.org, dave.hansen@intel.com, jglisse@redhat.com, akpm@linux-foundation.org, logang@deltatee.com, dan.j.williams@intel.com, kirill.shutemov@linux.intel.com Subject: Re: [PATCH 1/4] mm: Provide kernel parameter to allow disabling page init poisoning Message-ID: <20180912141053.GL10951@dhcp22.suse.cz> References: <20180910232615.4068.29155.stgit@localhost.localdomain> <20180910234341.4068.26882.stgit@localhost.localdomain> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20180910234341.4068.26882.stgit@localhost.localdomain> User-Agent: Mutt/1.10.1 (2018-07-13) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon 10-09-18 16:43:41, 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. I am still not convinced that this all is worth the additional code. It is much better than a new config option for sure. If we really want this though then I suggest that the parameter handler should note the disabled state (when CONFIG_DEBUG_VM is on) to the kernel log. I would also make it explicit who might want to do that in the parameter description. > + page_init_poison= [KNL] Boot-time parameter changing the > + state of poisoning of page structures during early > + boot. Used to verify page metadata is not accessed > + prior to initialization. Available with > + CONFIG_DEBUG_VM=y. > + off: turn off poisoning > + on: turn on poisoning (default) > + what about the following wording or something along those lines Boot-time parameter to control struct page poisoning which is a debugging feature to catch unitialized struct page access. This option is available only for CONFIG_DEBUG_VM=y and it affects boot time (especially on large systems). If there are no poisoning bugs reported on the particular system and workload it should be safe to disable it to speed up the boot time. -- Michal Hocko SUSE Labs