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 [PATCH] x86: create a non-zero sized bm_pte only when needed 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 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.