All of lore.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 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.