linuxppc-dev.lists.ozlabs.org archive mirror
 help / color / mirror / Atom feed
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.

  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).