Received: by 2002:ac0:a5a7:0:0:0:0:0 with SMTP id m36-v6csp4530245imm; Mon, 20 Aug 2018 18:19:03 -0700 (PDT) X-Google-Smtp-Source: AA+uWPwuH5LcZDpE/0WcBTXdTR0LcTEOeXHARt41yAPnsA7C+paYB/CSuA+H9aYJWoEVXjep2uF0 X-Received: by 2002:a63:4306:: with SMTP id q6-v6mr44684023pga.181.1534814343777; Mon, 20 Aug 2018 18:19:03 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1534814343; cv=none; d=google.com; s=arc-20160816; b=J4D3mNUa3H7+NZAIabbj8HqBWrL1+9GlwpAR5cTFHmSyn5A1zxNrI5dFCiHfMdcmUJ 6s+jy0qyLiWCverXOlIARAMwA7qFebI4hnFncjpNfZVuaKXrkIpT6fd9/w/Pa6j/T9LU MAGULaXoqyMsvFa9q+/rEQF2g4Ryq1/HWO6K4WEjLWyTjLUeB/0K4zsU+2aiOt4FF3+F XBggTWsaWCEXQv/JYxxp5litcmA3DAtGwHFehFBVS6sh61paPg5LaGdKnJSVniVY0zcz Iy/QfMk6cFNTpRqudoHk73ezT85p2p8rpIJqjoXd8o+ZlNiuOTGzNQQD7oh0P3zi/Tlb IEhQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:message-id:date:subject:to:from :arc-authentication-results; bh=/q3GjTwkATngzlVaLfCSdhaGD7eClF7Ihjn/JuXO+QY=; b=ZfZ0/wkvuna6FrCb27Se4puZ9u0nEp0QMsdSXztAyRJreo47sjtwX/rrbiOVzoJxul o4JQ/W/+nYppiIjvff1YSRitDMGlv/9vq9SyK3H8teP0izlDckZRyknBLgj6YGxDOV5r OnBP1jRnIKZF6FNnvh1ajtwYjKZPZiC5dRFuCpN5Y+2hMz9SeTZOYgFTNes+cG8Gsqk6 Ax0t2nZIsKRMTxcqyCES7ynTPp0YNyBDJNrTrztTBPKrN+T9skpIJHAHIJIYGjAoZd1o ggnw9fy1y7mjwyFa/vIhxDOO0SF7CIbChOy8rZl7fV0GTCSDYpnlDZrcRd7pCmCN1E1S lbOg== 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=intel.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id n70-v6si11588751pfa.320.2018.08.20.18.18.34; Mon, 20 Aug 2018 18:19:03 -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=intel.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726485AbeHUEec (ORCPT + 99 others); Tue, 21 Aug 2018 00:34:32 -0400 Received: from mga07.intel.com ([134.134.136.100]:17761 "EHLO mga07.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725733AbeHUEec (ORCPT ); Tue, 21 Aug 2018 00:34:32 -0400 X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from fmsmga003.fm.intel.com ([10.253.24.29]) by orsmga105.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 20 Aug 2018 18:16:36 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.53,267,1531810800"; d="scan'208";a="74359128" Received: from shbuild000.sh.intel.com (HELO byang_ol.sh.intel.com) ([10.239.144.215]) by FMSMGA003.fm.intel.com with ESMTP; 20 Aug 2018 18:16:34 -0700 From: Bin Yang To: tglx@linutronix.de, mingo@kernel.org, hpa@zytor.com, x86@kernel.org, linux-kernel@vger.kernel.org, peterz@infradead.org, dave.hansen@intel.com, mark.gross@intel.com, bin.yang@intel.com Subject: [PATCH v3 0/5] x86/mm: fix cpu stuck issue in __change_page_attr_set_clr Date: Tue, 21 Aug 2018 01:16:21 +0000 Message-Id: <1534814186-37067-1-git-send-email-bin.yang@intel.com> X-Mailer: git-send-email 2.7.4 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org One problem is found when optimizing the x86 kernel boot time, that sometimes the free_initmem() will take about 600ms, which is way too much for fast boot. When changing a 4K page attr inside the large page range, __change_page_attr() will call try_preserve_large_page() to decide to split the big page or not. And try_preserve_large_page() will call static_protections() to check all 4K pages inside the large page range one by one. free_initmem() <-- free N pages free_init_pages() set_memory_rw() change_page_attr_set() change_page_attr_set_clr() __change_page_attr_set_clr() __change_page_attr() <-- loop N times try_preserve_large_page() static_protections() <-- worst case: loop (1G/4K = 262144) * N times The problem is, most of the 256K * N times of call of static_proetections() is _not_ necessary at all, as pointed out by Thomas Gleixner : "The current code does the static_protection() check loop _before_ checking: 1) Whether the new and the old pgprot are the same 2) Whether the address range which needs to be changed is aligned to and covers the full large mapping It does the static_protections() loop before #1 and #2 which can be optimized." The static_protections() check loop can be optimized to check for overlapping ranges and then check explicitly for those without any looping. Here are 5 patches for these optimizations: Patch 1: check whether new pgprot is same as old pgprot first to avoid unnecessary static_protection() checking. Patch 2: check whether it is whole large page attr change first to avoid unnecessary static_protection() checking. Patch 3: add help function to check specific protection flags in range Patch 4: Optimize the static_protection() by using overlap() check instead of within() Patch 5: Add a check for catching a case where the existing mapping is wrong already The approach and some of the comments came from Thomas's email example for how to do this. Thanks again for Thomas's kind help. Thanks, Bin Bin Yang (5): x86/mm: avoid redundant checking if pgprot has no change x86/mm: avoid static_protection() checking if not whole large page attr change x86/mm: add help function to check specific protection flags in range x86/mm: optimize static_protection() by using overlap() x86/mm: add WARN_ON_ONCE() for wrong large page mapping arch/x86/mm/pageattr.c | 127 +++++++++++++++++++++++++++++++++---------------- 1 file changed, 86 insertions(+), 41 deletions(-) -- 2.7.4