Received: by 10.192.165.148 with SMTP id m20csp365626imm; Wed, 9 May 2018 14:09:59 -0700 (PDT) X-Google-Smtp-Source: AB8JxZrJJAnzp+I6TaSod+Zm095G//W3hP4MkHcOVp9aD1mGAN39PAupTR2tlilaWBFIqCDysBC6 X-Received: by 2002:a17:902:bb84:: with SMTP id m4-v6mr46520327pls.339.1525900199162; Wed, 09 May 2018 14:09:59 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1525900199; cv=none; d=google.com; s=arc-20160816; b=h70JC49rwcrwkTGgA1bTWx1hZJ7vvK7IwOOEGx9zDjCu2KpkuuupTC6HrGINlkTtQo yoU6G+eVZ5cBk1+erK9K38+DG9UjOyOs2RPPz0pbURZjgD56TtV66zhpbmDdDhESq8ob VVwNXjjdhp8nyX9vMb20c09CAXNvaS8yWMIBmQzm+KPK1O5lmDLrfWKEc6+XbE08vz5E +BsWVg3e55kcYDyHJz5fJiHGeuEEQsVSR21/zoc7B8p0NqgENWKB2Z2pCbgNOo99SEOD X8WzHc4e0AQNSsZfxoc1CPTWAQefuCIXpbne20mhJXYJM5Xyk8v9qqAs/GIMQs5kqAqC XsIg== 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:arc-authentication-results; bh=81d/nXvOV5wdvdYtWXFl8MumRw5+od80miYvJoM+3fw=; b=NPZMlgjYojdum8BlVqYdUnp+BpdIznkMvrx/5Y8+Uyxq4FsE1TuJniQ2fYtuAO9tLG /nzlyVa6/x6EruzSk3m4TFGsSp3Gh/u8aSlQm82QJlUYM83IUNbekZlaEw4Hb2zpjeWe tvRiiYWX2nsp1goy2xEQDiEkcR7InrwZJhu1ccT38ZDonVRYEpwUf5DF9rtdj7b/NUsP eET3ID/MlXg7KakNFDYg312ETZwQOAG+ezzN1vZR9X8bskLPGx2dw1bW/t4VldHiRLBS ip6y8XNfwjE1INVN8JihsFPCP97/x9NivWaqZo+44El4BRKfAxkTdaqrKpWmT/YLIwXF cCuw== 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 u3si29479598pfj.58.2018.05.09.14.09.44; Wed, 09 May 2018 14:09:59 -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 S965484AbeEIVJX (ORCPT + 99 others); Wed, 9 May 2018 17:09:23 -0400 Received: from mx2.suse.de ([195.135.220.15]:39105 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S964896AbeEIVJW (ORCPT ); Wed, 9 May 2018 17:09:22 -0400 X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (charybdis-ext.suse.de [195.135.220.254]) by mx2.suse.de (Postfix) with ESMTP id 6AE6DABE8; Wed, 9 May 2018 21:09:21 +0000 (UTC) Date: Wed, 9 May 2018 23:09:20 +0200 From: Michal Hocko To: Pavel Tatashin Cc: steven.sistare@oracle.com, daniel.m.jordan@oracle.com, akpm@linux-foundation.org, linux-kernel@vger.kernel.org, tglx@linutronix.de, linux-mm@kvack.org, mgorman@techsingularity.net, mingo@kernel.org, peterz@infradead.org, rostedt@goodmis.org, fengguang.wu@intel.com, dennisszhou@gmail.com Subject: Re: [PATCH] mm: allow deferred page init for vmemmap only Message-ID: <20180509210920.GZ32366@dhcp22.suse.cz> References: <20180509191713.23794-1-pasha.tatashin@oracle.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20180509191713.23794-1-pasha.tatashin@oracle.com> User-Agent: Mutt/1.9.5 (2018-04-13) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed 09-05-18 15:17:13, Pavel Tatashin wrote: > It is unsafe to do virtual to physical translations before mm_init() is > called if struct page is needed in order to determine the memory section > number (see SECTION_IN_PAGE_FLAGS). This is because only in mm_init() we > initialize struct pages for all the allocated memory when deferred struct > pages are used. > > My recent fix exposed this problem, because it greatly reduced number of > pages that are initialized before mm_init(), but the problem existed even > before my fix, as Fengguang Wu found. > > Since FLATMEM is already disallowed for deferred struct pages, it makes > sense to allow deferred struct pages only on systems with > SPARSEMEM_VMEMMAP. This doesn't really explain why CONFIG_SPARSMEM or DISCONTIG has the problem. > The problems are discussed in these threads: > http://lkml.kernel.org/r/20180418135300.inazvpxjxowogyge@wfg-t540p.sh.intel.com > http://lkml.kernel.org/r/20180419013128.iurzouiqxvcnpbvz@wfg-t540p.sh.intel.com > http://lkml.kernel.org/r/20180426202619.2768-1-pasha.tatashin@oracle.com Using references is good but there should be a highlevel summary in the chaneglog as well. > Fixes: 3a80a7fa7989 ("mm: meminit: initialise a subset of struct pages if CONFIG_DEFERRED_STRUCT_PAGE_INIT is set") > Signed-off-by: Pavel Tatashin > --- > mm/Kconfig | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/mm/Kconfig b/mm/Kconfig > index d5004d82a1d6..1cd32d67ca30 100644 > --- a/mm/Kconfig > +++ b/mm/Kconfig > @@ -635,7 +635,7 @@ config DEFERRED_STRUCT_PAGE_INIT > bool "Defer initialisation of struct pages to kthreads" > default n > depends on NO_BOOTMEM > - depends on !FLATMEM > + depends on SPARSEMEM_VMEMMAP > help > Ordinarily all struct pages are initialised during early boot in a > single thread. On very large machines this can take a considerable > -- > 2.17.0 > -- Michal Hocko SUSE Labs