All of lore.kernel.org
 help / color / mirror / Atom feed
From: Bin Yang <bin.yang@intel.com>
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 1/5] x86/mm: avoid redundant checking if pgprot has no change
Date: Tue, 21 Aug 2018 01:16:22 +0000	[thread overview]
Message-ID: <1534814186-37067-2-git-send-email-bin.yang@intel.com> (raw)
In-Reply-To: <1534814186-37067-1-git-send-email-bin.yang@intel.com>

In try_preserve_large_page(), the check for
pgprot_val(new_prot) == pgprot_val(old_port) can definitely
be done at first to avoid redundant checking.

The approach and some of the comments came from Thomas Gleixner's
email example for how to do this

Suggested-by: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Bin Yang <bin.yang@intel.com>
---
 arch/x86/mm/pageattr.c | 24 ++++++++++++++++--------
 1 file changed, 16 insertions(+), 8 deletions(-)

diff --git a/arch/x86/mm/pageattr.c b/arch/x86/mm/pageattr.c
index 8d6c34f..68613fd 100644
--- a/arch/x86/mm/pageattr.c
+++ b/arch/x86/mm/pageattr.c
@@ -629,6 +629,22 @@ try_preserve_large_page(pte_t *kpte, unsigned long address,
 	new_prot = static_protections(req_prot, address, pfn);
 
 	/*
+	 * The static_protections() is used to check specific protection flags
+	 * for certain areas of memory. The old pgprot should be checked already
+	 * when it was applied before. If it's not, then this is a bug in some
+	 * other code and needs to be fixed there.
+	 *
+	 * If new pgprot is same as old pgprot, return directly without any
+	 * additional checking. The following static_protections() checking is
+	 * pointless if pgprot has no change. It can avoid the redundant
+	 * checking and optimize the performance of large page split checking.
+	 */
+	if (pgprot_val(new_prot) == pgprot_val(old_prot)) {
+		do_split = 0;
+		goto out_unlock;
+	}
+
+	/*
 	 * We need to check the full range, whether
 	 * static_protection() requires a different pgprot for one of
 	 * the pages in the range we try to preserve:
@@ -642,14 +658,6 @@ try_preserve_large_page(pte_t *kpte, unsigned long address,
 			goto out_unlock;
 	}
 
-	/*
-	 * If there are no changes, return. maxpages has been updated
-	 * above:
-	 */
-	if (pgprot_val(new_prot) == pgprot_val(old_prot)) {
-		do_split = 0;
-		goto out_unlock;
-	}
 
 	/*
 	 * We need to change the attributes. Check, whether we can
-- 
2.7.4


  reply	other threads:[~2018-08-21  1:16 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-08-21  1:16 [PATCH v3 0/5] x86/mm: fix cpu stuck issue in __change_page_attr_set_clr Bin Yang
2018-08-21  1:16 ` Bin Yang [this message]
2018-09-03 21:57   ` [PATCH v3 1/5] x86/mm: avoid redundant checking if pgprot has no change Thomas Gleixner
2018-09-04  7:01     ` Yang, Bin
2018-09-04  7:49       ` Thomas Gleixner
2018-09-04  9:12         ` Yang, Bin
2018-09-04  9:22           ` Yang, Bin
2018-08-21  1:16 ` [PATCH v3 2/5] x86/mm: avoid static_protection() checking if not whole large page attr change Bin Yang
2018-08-21  1:16 ` [PATCH v3 3/5] x86/mm: add help function to check specific protection flags in range Bin Yang
2018-09-03 22:10   ` Thomas Gleixner
2018-09-04  6:22     ` Yang, Bin
2018-08-21  1:16 ` [PATCH v3 4/5] x86/mm: optimize static_protection() by using overlap() Bin Yang
2018-09-04 12:22   ` Thomas Gleixner
2018-09-07  1:14     ` Yang, Bin
2018-09-07  7:49       ` Thomas Gleixner
2018-09-07  8:04         ` Yang, Bin
2018-09-07  8:21           ` Thomas Gleixner
2018-09-07  8:26             ` Yang, Bin
2018-08-21  1:16 ` [PATCH v3 5/5] x86/mm: add WARN_ON_ONCE() for wrong large page mapping Bin Yang
2018-09-03 22:27   ` Thomas Gleixner
2018-09-04  6:32     ` Yang, Bin
2018-09-04  7:41       ` Thomas Gleixner
2018-09-04 16:52         ` Thomas Gleixner
2018-09-07  2:12           ` Yang, Bin

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1534814186-37067-2-git-send-email-bin.yang@intel.com \
    --to=bin.yang@intel.com \
    --cc=dave.hansen@intel.com \
    --cc=hpa@zytor.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mark.gross@intel.com \
    --cc=mingo@kernel.org \
    --cc=peterz@infradead.org \
    --cc=tglx@linutronix.de \
    --cc=x86@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.