linux-kernel.vger.kernel.org archive mirror
 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 0/5] x86/mm: fix cpu stuck issue in __change_page_attr_set_clr
Date: Tue, 21 Aug 2018 01:16:21 +0000	[thread overview]
Message-ID: <1534814186-37067-1-git-send-email-bin.yang@intel.com> (raw)


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


             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 Bin Yang [this message]
2018-08-21  1:16 ` [PATCH v3 1/5] x86/mm: avoid redundant checking if pgprot has no change Bin Yang
2018-09-03 21:57   ` 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-1-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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).