public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Wei Yang <richardw.yang@linux.intel.com>
To: x86@kernel.org, linux-kernel@vger.kernel.org
Cc: dave.hansen@linux.intel.com, luto@kernel.org,
	peterz@infradead.or, tglx@linutronix.de,
	Wei Yang <richardw.yang@linux.intel.com>
Subject: [PATCH 4/6] x86, mm: make split_mem_range() more easy to read
Date: Tue, 12 Feb 2019 10:12:13 +0800	[thread overview]
Message-ID: <20190212021215.13247-5-richardw.yang@linux.intel.com> (raw)
In-Reply-To: <20190212021215.13247-1-richardw.yang@linux.intel.com>

As the comment explains, there are at most 5 possible ranges:

              kkkmmmGGGmmmkkk
              (A)(B)(C)(D)(E)

While there are two ways to perceive:

    * C & D are extra ranges on X86_64
    * B & C are extra ranges on X86_64

Current implementation takes the first way, which leads to handling
end_pfn of B differently:

    * align to PMD on X86_32
    * align to PUD on X86_64

If we take the second way, we don't need to handle it differently.

    * the end_pfn of B only need to align to PUD
    * the end_pfn of D only need to align to PMD

This patch changes the implementation from the first perception to the
second to reduce one different handling on end_pfn. After doing so, the
code is easier to read.

Signed-off-by: Wei Yang <richardw.yang@linux.intel.com>
---
 arch/x86/mm/init.c | 8 ++------
 1 file changed, 2 insertions(+), 6 deletions(-)

diff --git a/arch/x86/mm/init.c b/arch/x86/mm/init.c
index 2b782dcd6d71..87275238dbb0 100644
--- a/arch/x86/mm/init.c
+++ b/arch/x86/mm/init.c
@@ -389,25 +389,21 @@ static int __meminit split_mem_range(struct map_range *mr,
 		pfn = end_pfn;
 	}
 
+#ifdef CONFIG_X86_64
 	/*
 	 * Range (B):
 	 * big page (2M) range
 	 */
 	start_pfn = round_up(pfn, PFN_DOWN(PMD_SIZE));
-#ifdef CONFIG_X86_32
-	end_pfn = round_down(limit_pfn, PFN_DOWN(PMD_SIZE));
-#else /* CONFIG_X86_64 */
 	end_pfn = round_up(pfn, PFN_DOWN(PUD_SIZE));
 	if (end_pfn > round_down(limit_pfn, PFN_DOWN(PMD_SIZE)))
 		end_pfn = round_down(limit_pfn, PFN_DOWN(PMD_SIZE));
-#endif
 	if (start_pfn < end_pfn) {
 		nr_range = save_mr(mr, nr_range, start_pfn, end_pfn,
 				page_size_mask & (1<<PG_LEVEL_2M));
 		pfn = end_pfn;
 	}
 
-#ifdef CONFIG_X86_64
 	/*
 	 * Range (C):
 	 * big page (1G) range
@@ -420,6 +416,7 @@ static int __meminit split_mem_range(struct map_range *mr,
 				 ((1<<PG_LEVEL_2M)|(1<<PG_LEVEL_1G)));
 		pfn = end_pfn;
 	}
+#endif
 
 	/*
 	 * Range (D):
@@ -432,7 +429,6 @@ static int __meminit split_mem_range(struct map_range *mr,
 				page_size_mask & (1<<PG_LEVEL_2M));
 		pfn = end_pfn;
 	}
-#endif
 
 	/*
 	 * Range (E):
-- 
2.19.1


  parent reply	other threads:[~2019-02-12  2:13 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-02-12  2:12 [PATCH 0/6] x86, mm: refine split_mem_range a little Wei Yang
2019-02-12  2:12 ` [PATCH 1/6] x86, mm: remove second argument of split_mem_range() Wei Yang
2019-03-24 14:38   ` Thomas Gleixner
2019-03-25  1:16     ` Wei Yang
2019-02-12  2:12 ` [PATCH 2/6] x86, mm: remove check in save_mr Wei Yang
2019-02-12  2:12 ` [PATCH 3/6] x86, mm: add comment for split_mem_range to help understanding Wei Yang
2019-02-12  2:12 ` Wei Yang [this message]
2019-03-24 14:29   ` [PATCH 4/6] x86, mm: make split_mem_range() more easy to read Thomas Gleixner
2019-03-27 22:05     ` Wei Yang
2019-03-28  0:16       ` Thomas Gleixner
2019-03-28  0:25         ` Wei Yang
2019-03-28  3:35     ` Wei Yang
2019-03-28  7:20     ` Wei Yang
2019-03-28  8:08       ` Thomas Gleixner
2019-03-29  3:38         ` Wei Yang
     [not found]     ` <20190328065117.GA6202@richard>
2019-03-28  8:02       ` Thomas Gleixner
2019-04-12  3:08     ` Wei Yang
2019-02-12  2:12 ` [PATCH 5/6] x86, mm: skip 1G range if the range doesn't span PUD Wei Yang
2019-02-12  2:12 ` [PATCH 6/6] x86, mm: x86, mm: jump to split only 4K range when range doesn't span PMD Wei Yang

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=20190212021215.13247-5-richardw.yang@linux.intel.com \
    --to=richardw.yang@linux.intel.com \
    --cc=dave.hansen@linux.intel.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=luto@kernel.org \
    --cc=peterz@infradead.or \
    --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