From patchwork Mon May 23 18:15:56 2016 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Yang Shi X-Patchwork-Id: 68408 Delivered-To: patch@linaro.org Received: by 10.140.92.199 with SMTP id b65csp236436qge; Mon, 23 May 2016 11:43:16 -0700 (PDT) X-Received: by 10.66.159.102 with SMTP id xb6mr410510pab.73.1464028996523; Mon, 23 May 2016 11:43:16 -0700 (PDT) Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id dz4si53532769pab.12.2016.05.23.11.43.16; Mon, 23 May 2016 11:43:16 -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=@linaro.org; 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 dis=NONE) header.from=linaro.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754623AbcEWSnN (ORCPT + 30 others); Mon, 23 May 2016 14:43:13 -0400 Received: from mail-pa0-f52.google.com ([209.85.220.52]:33259 "EHLO mail-pa0-f52.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753153AbcEWSnL (ORCPT ); Mon, 23 May 2016 14:43:11 -0400 Received: by mail-pa0-f52.google.com with SMTP id xk12so64837453pac.0 for ; Mon, 23 May 2016 11:43:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=from:to:cc:subject:date:message-id; bh=IfxjRwlC1EnQ/34GeB32D94HNBpeXna32L12rcKczAg=; b=ioPsLimSgap0O6z0NEKaiE6E6CVejZXXsphZAh3i9brrJDasqBoqfUkuSMrtLQpN7r Ky/GZH7roGKHA6JV45O18bpZBiYg3S7ldZlXUBmyvdbc6/8q2lcFexrh1BcjGkqiybJ7 WX082fKLxJxwYjP6ve68iFto536IdOF+CsmrM= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:cc:subject:date:message-id; bh=IfxjRwlC1EnQ/34GeB32D94HNBpeXna32L12rcKczAg=; b=GdV0DRHbukwWEnE7xw+3g+kp+0/EKm3uWgZ1TLLETZ8vfNpbydUwqWC3SjdY1ZWyPC 3M815ZjaFMRn5eo+pHUIOOJyQhXH9sWvJaj8pVEMp5T6gaQ9RqaoUMQ83xxIEqL2AWlO yvhKwdP1fLZ1N2sfxnIYuK2sX/EZqVDSvauPYfMNNcYsUDiX3JEp9KK58n1UBQcnZEhK d3/AkxgogwlaE4uPIpA+0o++Jya4I3oZc8Y8zxyornVHiY4b4a/e+w8CMJBCoXKJ1X7u kbx7RKia5A5HS/HVJc2MgMNfHt0GNrcGONMlBI6XKPnk3SYBgZ7fXat6r1Ld8aBBaH70 C5DQ== X-Gm-Message-State: ALyK8tIK/5a8RonVYdGfI0nyJORHu82GylyC5Jjr2SdvvOaTT0oH3iw2YO4Rcf7WZdk9QdVH X-Received: by 10.66.112.34 with SMTP id in2mr491433pab.52.1464028990684; Mon, 23 May 2016 11:43:10 -0700 (PDT) Received: from yshi-Precision-T5600.corp.ad.wrs.com (unknown-216-82.windriver.com. [147.11.216.82]) by smtp.gmail.com with ESMTPSA id zs16sm48472449pab.13.2016.05.23.11.43.09 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 23 May 2016 11:43:09 -0700 (PDT) From: Yang Shi To: akpm@linux-foundation.org, mhocko@kernel.org Cc: linux-kernel@vger.kernel.org, linux-mm@kvack.org, linaro-kernel@lists.linaro.org, yang.shi@linaro.org Subject: [v2 PATCH] mm: make CONFIG_DEFERRED_STRUCT_PAGE_INIT depends on !FLATMEM explicitly Date: Mon, 23 May 2016 11:15:56 -0700 Message-Id: <1464027356-32282-1-git-send-email-yang.shi@linaro.org> X-Mailer: git-send-email 2.0.2 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Per the suggestion from Michal Hocko [1], DEFERRED_STRUCT_PAGE_INIT requires some ordering wrt other initialization operations, e.g. page_ext_init has to happen after the whole memmap is initialized properly. For SPARSEMEM this requires to wait for page_alloc_init_late. Other memory models (e.g. flatmem) might have different initialization layouts (page_ext_init_flatmem). Currently DEFERRED_STRUCT_PAGE_INIT depends on MEMORY_HOTPLUG which in turn depends on SPARSEMEM || X86_64_ACPI_NUMA depends on ARCH_ENABLE_MEMORY_HOTPLUG and X86_64_ACPI_NUMA depends on NUMA which in turn disable FLATMEM memory model: config ARCH_FLATMEM_ENABLE def_bool y depends on X86_32 && !NUMA so FLATMEM is ruled out via dependency maze. Be explicit and disable FLATMEM for DEFERRED_STRUCT_PAGE_INIT so that we do not reintroduce subtle initialization bugs [1] http://lkml.kernel.org/r/20160523073157.GD2278@dhcp22.suse.cz CC: Michal Hocko Signed-off-by: Yang Shi --- v2: Adopted Michal's comments for the commit log mm/Kconfig | 1 + 1 file changed, 1 insertion(+) -- 2.0.2 diff --git a/mm/Kconfig b/mm/Kconfig index 2664c11..22fa818 100644 --- a/mm/Kconfig +++ b/mm/Kconfig @@ -649,6 +649,7 @@ config DEFERRED_STRUCT_PAGE_INIT default n depends on ARCH_SUPPORTS_DEFERRED_STRUCT_PAGE_INIT depends on MEMORY_HOTPLUG + depends on !FLATMEM help Ordinarily all struct pages are initialised during early boot in a single thread. On very large machines this can take a considerable