Received: by 2002:ac0:a5a6:0:0:0:0:0 with SMTP id m35-v6csp663127imm; Thu, 6 Sep 2018 08:15:44 -0700 (PDT) X-Google-Smtp-Source: ANB0VdZRe9dC5zU2kO6jdIuwWgqOfVGvxwSAI1PDGzp3EQkLvQZo5jlj+mLoge8rNnlGT9+1iwuo X-Received: by 2002:a63:e60c:: with SMTP id g12-v6mr3317490pgh.308.1536246944207; Thu, 06 Sep 2018 08:15:44 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1536246944; cv=none; d=google.com; s=arc-20160816; b=BSVuP0bSMP/G0r/CU4vAPWz4S6HWBkqU8KNTPqos+J9+xLmse2lMmKqx2DlOw4d9dr 0E0wQClGFtK6IWWP/6qjf5g+z9R8/614RqkiUB93tZZqvB9Oed3rfrQ08VsqkiwLhfeD 4sXYoA7WNve+KolOTeRKCc7cV6bd44uXPQA2QLfEwgi7Nmsu2CIiOLrL8ZUMDMa9DC1E +lJFXBZuMswftS7GCkU13XTgx7uReNgzNIA6U5tSlPm5VEHXqPVXGJmIFvdRg6Sv1POe xl2of/BBe049B9jb3b0K56jysSmZft5rDHnF0EKa1XhJNRMwoxWln0yS+utEAIrQBnkL ZXxQ== 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=tM+6b80dtnsbWXEZ+WRR0m6MHEk039ETGKTaW62vbLE=; b=hhKIBAHPnxtxfIYyMH8Z4uiS+EqTqjm6q5Ly3A9l1NQk071ffix+v+4PbN4K56KSz6 kLcXlTiL2If3Ip7V2RSkPRcmGVqsKLsetkKWrgdVAcmsvQhdRsfi01TcBR93V0yRvZ64 J95inTPNqfiphlMsi2MGSBmwfF446NvCKJDlqc0Qe+LAaFStusUpU5ljHXIPd5q9eyeE HRevF9qmnHJwwlEZNT+zCS/G1AN1weTYESRxkN3XOwt2CgaUFJsS8XBN3NYiYlhkDX82 PlCKWEQYbGF0e8fTVl3z1NS25x2FiwmLGaV/ivND2tY84hGwnHuQOz4skgvH5Dc8m44X Fs0w== 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 e205-v6si5287638pfh.158.2018.09.06.08.15.28; Thu, 06 Sep 2018 08:15:44 -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 S1730231AbeIFTth (ORCPT + 99 others); Thu, 6 Sep 2018 15:49:37 -0400 Received: from mx2.suse.de ([195.135.220.15]:33078 "EHLO mx1.suse.de" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1727501AbeIFTth (ORCPT ); Thu, 6 Sep 2018 15:49:37 -0400 X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay1.suse.de (unknown [195.135.220.254]) by mx1.suse.de (Postfix) with ESMTP id 84219AE4D; Thu, 6 Sep 2018 15:13:37 +0000 (UTC) Date: Thu, 6 Sep 2018 17:13:36 +0200 From: Michal Hocko To: Dave Hansen Cc: Alexander Duyck , linux-mm@kvack.org, linux-kernel@vger.kernel.org, alexander.h.duyck@intel.com, pavel.tatashin@microsoft.com, akpm@linux-foundation.org, mingo@kernel.org, kirill.shutemov@linux.intel.com Subject: Re: [PATCH v2 1/2] mm: Move page struct poisoning to CONFIG_DEBUG_VM_PAGE_INIT_POISON Message-ID: <20180906151336.GD14951@dhcp22.suse.cz> References: <20180905211041.3286.19083.stgit@localhost.localdomain> <20180905211328.3286.71674.stgit@localhost.localdomain> <20180906054735.GJ14951@dhcp22.suse.cz> <0c1c36f7-f45a-8fe9-dd52-0f60b42064a9@intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <0c1c36f7-f45a-8fe9-dd52-0f60b42064a9@intel.com> 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 Thu 06-09-18 07:59:03, Dave Hansen wrote: > On 09/05/2018 10:47 PM, Michal Hocko wrote: > > why do you have to keep DEBUG_VM enabled for workloads where the boot > > time matters so much that few seconds matter? > > There are a number of distributions that run with it enabled in the > default build. Fedora, for one. We've basically assumed for a while > that we have to live with it in production environments. > > So, where does leave us? I think we either need a _generic_ debug > option like: > > CONFIG_DEBUG_VM_SLOW_AS_HECK > > under which we can put this an other really slow VM debugging. Or, we > need some kind of boot-time parameter to trigger the extra checking > instead of a new CONFIG option. I strongly suspect nobody will ever enable such a scary looking config TBH. Besides I am not sure what should go under that config option. Something that takes few cycles but it is called often or one time stuff that takes quite a long but less than aggregated overhead of the former? Just consider this particular case. It basically re-adds an overhead that has always been there before the struct page init optimization went it. The poisoning just returns it in a different form to catch potential left overs. And we would like to have as many people willing to running in debug mode to test for those paths because they are basically impossible to review by the code inspection. More importantnly the major overhead is boot time so my question still stands. Is this worth a separate config option almost nobody is going to enable? Enabling DEBUG_VM by Fedora and others serves us a very good testing coverage and I appreciate that because it has generated some useful bug reports. Those people are paying quite a lot of overhead in runtime which can aggregate over time is it so much to ask about one time boot overhead? -- Michal Hocko SUSE Labs