From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
To: David Gibson <david@gibson.dropbear.id.au>
Cc: linuxppc-dev@ozlabs.org
Subject: Re: [2/6] Cleanup management of kmem_caches for pagetables
Date: Tue, 27 Oct 2009 13:28:19 +1100 [thread overview]
Message-ID: <1256610499.2076.69.camel@pasglop> (raw)
In-Reply-To: <20091016052212.E565EB7BBB@ozlabs.org>
On Fri, 2009-10-16 at 16:22 +1100, David Gibson wrote:
Minor nits... if you can respin today I should push it out to -next
> +void pgtable_cache_add(unsigned shift, void (*ctor)(void *))
> +{
> + char *name;
> + unsigned long table_size = sizeof(void *) << shift;
> + unsigned long align = table_size;
This is a bit thick.. could use some air. Just separate the definitions
from the assignments so you can make the code breath a bit :-)
Also the above warrants a comment explaining that this won't work for
PTE pages since sizeof(PTE) >= sizeof(void *) and the day we finally
move out of pte page == struct page, the code here will have to be
adapted.
> + /* When batching pgtable pointers for RCU freeing, we store
> + * the index size in the low bits. Table alignment must be
> + * big enough to fit it */
> + unsigned long minalign = MAX_PGTABLE_INDEX_SIZE + 1;
> + struct kmem_cache *new;
> +
> + /* It would be nice if this was a BUILD_BUG_ON(), but at the
> + * moment, gcc doesn't seem to recognize is_power_of_2 as a
> + * constant expression, so so much for that. */
> + BUG_ON(!is_power_of_2(minalign));
> + BUG_ON((shift < 1) || (shift > MAX_PGTABLE_INDEX_SIZE));
> +
> + if (PGT_CACHE(shift))
> + return; /* Already have a cache of this size */
Blank line here too
> + align = max_t(unsigned long, align, minalign);
> + name = kasprintf(GFP_KERNEL, "pgtable-2^%d", shift);
> + new = kmem_cache_create(name, table_size, align, 0, ctor);
> + PGT_CACHE(shift) = new;
And here
> + pr_debug("Allocated pgtable cache for order %d\n", shift);
> +}
> +
>
> void pgtable_cache_init(void)
> {
> - pgtable_cache[0] = kmem_cache_create(pgtable_cache_name[0], PGD_TABLE_SIZE, PGD_TABLE_SIZE, SLAB_PANIC, pgd_ctor);
> - pgtable_cache[1] = kmem_cache_create(pgtable_cache_name[1], PMD_TABLE_SIZE, PMD_TABLE_SIZE, SLAB_PANIC, pmd_ctor);
> + pgtable_cache_add(PGD_INDEX_SIZE, pgd_ctor);
> + pgtable_cache_add(PMD_INDEX_SIZE, pmd_ctor);
> + if (!PGT_CACHE(PGD_INDEX_SIZE) || !PGT_CACHE(PMD_INDEX_SIZE))
> + panic("Couldn't allocate pgtable caches");
> + BUG_ON(PUD_INDEX_SIZE && !PGT_CACHE(PUD_INDEX_SIZE));
> }
panic vs. BUG_ON() ... could be a bit more consistent.
> #ifdef CONFIG_SPARSEMEM_VMEMMAP
> Index: working-2.6/arch/powerpc/include/asm/pgalloc-64.h
> ===================================================================
> --- working-2.6.orig/arch/powerpc/include/asm/pgalloc-64.h 2009-10-16 12:53:45.000000000 +1100
> +++ working-2.6/arch/powerpc/include/asm/pgalloc-64.h 2009-10-16 12:53:51.000000000 +1100
> @@ -11,27 +11,30 @@
> #include <linux/cpumask.h>
> #include <linux/percpu.h>
>
> +/*
> + * This needs to be big enough to allow any pagetable sizes we need,
> + * but small enough to fit in the low bits of any page table pointer.
> + * In other words all pagetables, even tiny ones, must be aligned to
> + * allow at least enough low 0 bits to contain this value.
> + */
> +#define MAX_PGTABLE_INDEX_SIZE 0xf
This also has the constraint of being a (power of 2) - 1... worth
mentioning somewhere ?
Also if you could comment somewhere that index size == 0 means a PTE
page ? Not totally obvious at first.
Cheers,
Ben.
next prev parent reply other threads:[~2009-10-27 2:28 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-10-16 5:21 [0/6] Assorted hugepage cleanups (v3) David Gibson
2009-10-16 5:22 ` [6/6] Bring hugepage PTE accessor functions back into sync with normal accessors David Gibson
2009-10-16 5:22 ` [2/6] Cleanup management of kmem_caches for pagetables David Gibson
2009-10-27 2:28 ` Benjamin Herrenschmidt [this message]
2009-10-27 3:46 ` David Gibson
2009-10-27 4:30 ` Benjamin Herrenschmidt
2009-10-16 5:22 ` [4/6] Cleanup initialization of hugepages on powerpc David Gibson
2009-10-16 5:22 ` [1/6] Make hpte_need_flush() correctly mask for multiple page sizes David Gibson
2009-10-16 5:22 ` [5/6] Split hash MMU specific hugepage code into a new file David Gibson
2009-10-16 5:22 ` [3/6] Allow more flexible layouts for hugepage pagetables David Gibson
2009-10-27 3:10 ` Benjamin Herrenschmidt
2009-10-27 4:56 ` David Gibson
-- strict thread matches above, loose matches on Subject: below --
2009-10-27 5:22 [0/6] Assorted hugepage cleanups (v4) David Gibson
2009-10-27 5:24 ` [2/6] Cleanup management of kmem_caches for pagetables David Gibson
2009-10-29 2:27 ` David Gibson
2009-10-30 3:39 ` David Gibson
2009-10-30 5:05 ` David Gibson
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=1256610499.2076.69.camel@pasglop \
--to=benh@kernel.crashing.org \
--cc=david@gibson.dropbear.id.au \
--cc=linuxppc-dev@ozlabs.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).