From: Jeremy Fitzhardinge <jeremy@goop.org>
To: Jan Beulich <jbeulich@novell.com>
Cc: mingo@elte.hu, tglx@linutronix.de, hpa@zytor.com,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH] x86: create a non-zero sized bm_pte only when needed
Date: Mon, 16 Mar 2009 15:34:40 -0700 [thread overview]
Message-ID: <49BED400.6040605@goop.org> (raw)
In-Reply-To: <49B91826.76E4.0078.0@novell.com>
Jan Beulich wrote:
> Impact: kernel image size reduction
>
> Since in most configurations the pmd page needed maps the same range of
> virtual addresses which is also mapped by the earlier inserted one for
> covering FIX_DBGP_BASE, that page (and its insertion in the page
> tables) can be avoided altogether by detecting the condition at compile
> time.
>
Does this depend on CONFIG_EARLY_PRINTK_DBGP being set? And what's so
special about FIX_DBGP_BASE, that we should hard-code it in here? Is it
just that its the first non-arch-dependent fixmap slot? Or something
else? Will it break if we move FIX_DBGP_BASE?
Is the space saving here just the 1 page for bm_pte[]? Wouldn't we do
as well by making it initdata?
I'm picking on this change because its breaking Xen PV booting...
> static __initdata int after_paging_init;
> -static pte_t bm_pte[PAGE_SIZE/sizeof(pte_t)] __page_aligned_bss;
> +#define __FIXADDR_TOP (-PAGE_SIZE)
>
Will this break in a 32-bit PV kernel where FIXADDR_TOP is shifted?
This seriously needs a good inline comment.
> +static pte_t bm_pte[(__fix_to_virt(FIX_DBGP_BASE)
> + ^ __fix_to_virt(FIX_BTMAP_BEGIN)) >> PMD_SHIFT
> + ? PAGE_SIZE / sizeof(pte_t) : 0] __page_aligned_bss;
> +#undef __FIXADDR_TOP
> +static __initdata pte_t *bm_ptep;
>
> static inline pmd_t * __init early_ioremap_pmd(unsigned long addr)
> {
> @@ -505,6 +510,8 @@ static inline pmd_t * __init early_iorem
>
> static inline pte_t * __init early_ioremap_pte(unsigned long addr)
> {
> + if (!sizeof(bm_pte))
> + return &bm_ptep[pte_index(addr)];
> return &bm_pte[pte_index(addr)];
>
Why not just assign bm_ptep = bm_pte if we're using the array?
> }
>
> @@ -516,8 +523,14 @@ void __init early_ioremap_init(void)
> printk(KERN_INFO "early_ioremap_init()\n");
>
> pmd = early_ioremap_pmd(fix_to_virt(FIX_BTMAP_BEGIN));
> - memset(bm_pte, 0, sizeof(bm_pte));
> - pmd_populate_kernel(&init_mm, pmd, bm_pte);
> + if (sizeof(bm_pte)) {
> + memset(bm_pte, 0, sizeof(bm_pte));
> + pmd_populate_kernel(&init_mm, pmd, bm_pte);
> + } else {
> + bm_ptep = pte_offset_kernel(pmd, 0);
> + if (early_ioremap_debug)
> + printk(KERN_INFO "bm_ptep=%p\n", bm_ptep);
> + }
J
next prev parent reply other threads:[~2009-03-16 22:35 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-03-12 13:11 Jan Beulich
2009-03-13 2:34 ` [tip:x86/mm] " Jan Beulich
2009-03-16 22:34 ` Jeremy Fitzhardinge [this message]
2009-03-17 7:41 ` [PATCH] " Jan Beulich
2009-03-17 18:33 ` Jeremy Fitzhardinge
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=49BED400.6040605@goop.org \
--to=jeremy@goop.org \
--cc=hpa@zytor.com \
--cc=jbeulich@novell.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
--cc=tglx@linutronix.de \
/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
Powered by JetHome