Received: by 10.213.65.68 with SMTP id h4csp680942imn; Tue, 13 Mar 2018 18:00:58 -0700 (PDT) X-Google-Smtp-Source: AG47ELuSRzdQcAHJVuywxXie6/zo7LME1DkgJ43zywV7T4JR92Rw5c08+1/rKnqiWlpe9W1lb/+8 X-Received: by 2002:a17:902:b901:: with SMTP id bf1-v6mr2234835plb.175.1520989258124; Tue, 13 Mar 2018 18:00:58 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1520989258; cv=none; d=google.com; s=arc-20160816; b=YRRiVGFcYKSJf0A04kDE7nJM+xO/XOEpISgVfYmh50wtMGgA/9JNrSfOsV3/GpdgfS Iq6iC30PfpVnIE4zluQ/giFzMXy32a4ecCRuYLs+m7/MQKCwX2fFaeJY+3XycIUpqgyJ Ca/RtEFf1CwsbwrjCdXWEPf09x9Dii8+sK/f36BIUx9eKWglxh9Mn88ddhpW4OvPOxXo oYlMq+bULI8QL1oWbXdlBCXxiylf151cEECio8KfDepvHWwp5Ya1SpclLCbAAnY5geuq qa7OVUeNfDjyVRI2+JZxVqg7H9jzGC3WkOjZf6XJWorR2gg5pbMI3UxZnHDP4JQt3sux zVKA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:cc:to:subject :message-id:date:from:references:in-reply-to:mime-version :dkim-signature:arc-authentication-results; bh=zrVbNCfx9ckAihd3WO4FlglKf/c4OmT6Pvaz7OgBsIE=; b=yJRD34RqhI/ESi3BfDgYxQvxy4Jbbe0Vspz6+vsoxeAk+zltEZrp9x5uWbsqjFai+m DiuamlTEVKS5JC9vwHSuL9YBvAxPGbUnDcpo96ucJfCJw/qmMwmO0QE/gCmlkNbpzb54 q2slurh4Kf9tQOrvfh1sMM0VeZn7jPA9l9vd+Mbpar5nMLfRqCKh4TYdse3EKcnMuKRg 99h3ApOjW5wSFf/v00WJDzn6RsBXGdGUuwP6aAHMYUKlBJg9D7p2IPWNfUowtdFHykaw Jdh/PwXToEtqigbUfYy7TfLjpCFXgvghr0MQfcMuf1AY1qJk/jzjwWUfmdq+DkAmsOQs ggfQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@oracle.com header.s=corp-2017-10-26 header.b=i0fAt7xg; 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=NONE dis=NONE) header.from=oracle.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id z13si1055115pfh.217.2018.03.13.18.00.43; Tue, 13 Mar 2018 18:00:58 -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=@oracle.com header.s=corp-2017-10-26 header.b=i0fAt7xg; 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=NONE dis=NONE) header.from=oracle.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S933034AbeCNA7t (ORCPT + 99 others); Tue, 13 Mar 2018 20:59:49 -0400 Received: from userp2120.oracle.com ([156.151.31.85]:57350 "EHLO userp2120.oracle.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932718AbeCNA7r (ORCPT ); Tue, 13 Mar 2018 20:59:47 -0400 Received: from pps.filterd (userp2120.oracle.com [127.0.0.1]) by userp2120.oracle.com (8.16.0.22/8.16.0.22) with SMTP id w2E0w1Ue129616 for ; Wed, 14 Mar 2018 00:59:47 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com; h=mime-version : in-reply-to : references : from : date : message-id : subject : to : cc : content-type : content-transfer-encoding; s=corp-2017-10-26; bh=zrVbNCfx9ckAihd3WO4FlglKf/c4OmT6Pvaz7OgBsIE=; b=i0fAt7xg612/ibxGW9aBcjSG9+0sQXcfxUz5O5UgLn7rppqkSzdKHSz/ghz48MRTvJDx U1843eKXMxYwMBGUkPkOvxcFOC493A3iFHqHnEYmZ52acTUXCxp7mUmMXxMUT3TRZbo5 nn9uA1aK9A6Ifq03MPwmKaJ47tmKMlOcHDWk2G/goiH3UUnJe8nHcVKbvBMcdAPVBjJE vPjs6VDPzfkG7bywA9IfSV8Bhom3r526BZzoyeWeLM/fYEOV/lJkONNgBllgdakXsDMC dxJ3JwSpw0Nwzx4qZNxUPI9AoykMMIqe8wcDuZvSkY3mxl0HR/PIwKItG6taNdSFqoEA CA== Received: from userv0021.oracle.com (userv0021.oracle.com [156.151.31.71]) by userp2120.oracle.com with ESMTP id 2gps3bg25v-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK) for ; Wed, 14 Mar 2018 00:59:46 +0000 Received: from userv0121.oracle.com (userv0121.oracle.com [156.151.31.72]) by userv0021.oracle.com (8.14.4/8.14.4) with ESMTP id w2E0xkPe017308 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK) for ; Wed, 14 Mar 2018 00:59:46 GMT Received: from abhmp0018.oracle.com (abhmp0018.oracle.com [141.146.116.24]) by userv0121.oracle.com (8.14.4/8.13.8) with ESMTP id w2E0xjpp012612 for ; Wed, 14 Mar 2018 00:59:45 GMT Received: from mail-ot0-f174.google.com (/74.125.82.174) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 13 Mar 2018 17:59:45 -0700 Received: by mail-ot0-f174.google.com with SMTP id 108-v6so1623978otv.3 for ; Tue, 13 Mar 2018 17:59:45 -0700 (PDT) X-Gm-Message-State: AElRT7H/cRVwVE2ktL5D2u0qr8ZPJOdZ2l/pcJMe1mGFXB6BDmkoulS+ L0kVgFOCa6l2lBdscGGFSWtRfJoYeGPi9QTEjVU= X-Received: by 10.157.9.163 with SMTP id q32mr246349otd.11.1520989185008; Tue, 13 Mar 2018 17:59:45 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a9d:7258:0:0:0:0:0 with HTTP; Tue, 13 Mar 2018 17:59:04 -0700 (PDT) In-Reply-To: <20180313142412.d373318b81164c4cb4b864b3@linux-foundation.org> References: <20180309220807.24961-1-pasha.tatashin@oracle.com> <20180309220807.24961-2-pasha.tatashin@oracle.com> <20180312130410.e2fce8e5e38bc2086c7fd924@linux-foundation.org> <20180313160430.hbjnyiazadt3jwa6@xakep.localdomain> <20180313115549.7badec1c6b85eb5a1cf21eb6@linux-foundation.org> <20180313194546.k62tni4g4gnds2nx@xakep.localdomain> <20180313131156.f156abe1822a79ec01c4800a@linux-foundation.org> <20180313142412.d373318b81164c4cb4b864b3@linux-foundation.org> From: Pavel Tatashin Date: Tue, 13 Mar 2018 20:59:04 -0400 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [v5 1/2] mm: disable interrupts while initializing deferred pages To: Andrew Morton Cc: Steven Sistare , Daniel Jordan , Masayoshi Mizuma , Michal Hocko , Catalin Marinas , AKASHI Takahiro , Gioh Kim , Heiko Carstens , Yaowei Bai , Wei Yang , Paul Burton , Miles Chen , Vlastimil Babka , Mel Gorman , Johannes Weiner , LKML , linux-mm@kvack.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Proofpoint-Virus-Version: vendor=nai engine=5900 definitions=8831 signatures=668690 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=1 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1803140007 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org > hm, maybe. But I'm not sure that touch_nmi_watchdog() will hold off a > soft lockup warning. Maybe it will. It should: 124static inline void touch_nmi_watchdog(void) 125{ 126 arch_touch_nmi_watchdog(); 127 touch_softlockup_watchdog(); 128} > > And please let's get the above thoughts into the changlog. OK > >> > >> > I'm not sure what to suggest, really. Your changelog isn't the best: >> > "Vlastimil Babka reported about a window issue during which when >> > deferred pages are initialized, and the current version of on-demand >> > initialization is finished, allocations may fail". Well... where is >> > ths mysterious window? Without such detail it's hard for others to >> > suggest alternative approaches. >> >> Here is hopefully a better description of the problem: >> >> Currently, during boot we preinitialize some number of struct pages to s= atisfy all boot allocations. Even if these allocations happen when we initi= alize the reset of deferred pages in page_alloc_init_late(). The problem is= that we do not know how much kernel will need, and it also depends on vari= ous options. >> >> So, with this work, we are changing this behavior to initialize struct p= ages on-demand, only when allocations happen. >> >> During boot, when we try to allocate memory, the on-demand struct page i= nitialization code takes care of it. But, once the deferred pages are initi= alizing in: >> >> page_alloc_init_late() >> for_each_node_state(nid, N_MEMORY) >> kthread_run(deferred_init_memmap()) >> >> We cannot use on-demand initialization, as these threads resize pgdat. >> >> This whole thing is to take care of this time. >> >> My first version of on-demand deferred page initialization would simply = fail to allocate memory during this period of time. But, this new version w= aits for threads to finish initializing deferred memory, and successfully p= erform the allocation. >> >> Because interrupt handler would wait for pgdat resize lock. > > OK, thanks. Please also add to changelog. OK, I will send an updated patch, with changelog changes.