linuxppc-dev.lists.ozlabs.org archive mirror
 help / color / mirror / Atom feed
From: David Gibson <david@gibson.dropbear.id.au>
To: Ilya Yanok <yanok@emcraft.com>
Cc: linuxppc-dev@ozlabs.org, wd@denx.de, dzu@denx.de
Subject: Re: [PATCH] powerpc: add support for PAGE_SIZEs greater than 4KB for
Date: Mon, 29 Sep 2008 12:58:13 +1000	[thread overview]
Message-ID: <20080929025813.GA8694@yookeroo.seuss> (raw)
In-Reply-To: <48DD71BF.9050204@emcraft.com>

On Sat, Sep 27, 2008 at 03:35:27AM +0400, Ilya Yanok wrote:
> Hello David,
>
> David Gibson wrote:
>> I don't see any reason to have a separate set of config options for 32
>> and 64-bit.  Just make the once choice, but only have the individual
>> pagesize options enabled on machines that support them.
>
> Well. I can see some. First, on PPC64 kernel emulates 64K pages on  
> hardware that can't do it and we are not going to do such an emulation  
> on PPC32 now.

So?

> Then CONFIG_PPC_64K_PAGES selects PPC_HAS_HASH_64K and our  
> code has nothing to do with it. 

Well, obviously the generic 64K option wouldn't select
PPC_HAS_HASH_64K.  That would be dependent on both 64K_PAGES and
PPC64.

> And last but not least, we don't use  
> PPC64 kernels for now so we just tried not to break something we can't  
> test. But if everybody thinks that having a single option is a good idea  
> I'll do it that way.

Hrm, well that has something to be said for it.  But it's not hard to
at least build a ppc64 kernel to test if you've broken that.

>> I don't think you should need a real_pte_t type for the 32-bit
>> implementation.  It's just there because of how we implement
>> 64k granularity page allocation on hardware that only does 4k
>> translations.
>
> You are right. Thanks.
>
>>> diff --git a/arch/powerpc/include/asm/page_32.h b/arch/powerpc/include/asm/page_32.h
>>> index ebfae53..d176270 100644
>>> --- a/arch/powerpc/include/asm/page_32.h
>>> +++ b/arch/powerpc/include/asm/page_32.h
>>> @@ -20,7 +20,11 @@
>>>   */
>>>  #ifdef CONFIG_PTE_64BIT
>>>  typedef unsigned long long pte_basic_t;
>>> +#ifdef CONFIG_PPC32_256K_PAGES
>>> +#define PTE_SHIFT	(PAGE_SHIFT - 7)
>>>     
>>
>> This doesn't look right.  You should be eliding one of the levels of
>> page table if you don't need it, rather than leaving the bottom level
>> PTE page largely empty.
>
> Hm... We have only two levels really so if we elide one there will be  
> only one left. Don't sure if kernel can work with this...

Ah.. that's a point.  But again this is a 256K specific hack, so we
can worry about it later.

>>> +#if (PAGE_SHIFT == 12)
>>> +/*
>>> + * PAGE_SIZE  4K
>>> + * PAGE_SHIFT 12
>>> + * PTE_SHIFT   9
>>> + * PMD_SHIFT  21
>>> + */
>>> +#define PPC44x_TLBE_SIZE	PPC44x_TLB_4K
>>> +#define PPC44x_PGD_OFF_SH	13 /*(32 - PMD_SHIFT + 2)*/
>>> +#define PPC44x_PGD_OFF_M1	19 /*(PMD_SHIFT - 2)*/
>>> +#define PPC44x_PTE_ADD_SH	23 /*32 - PMD_SHIFT + PTE_SHIFT + 3*/
>>> +#define PPC44x_PTE_ADD_M1	20 /*32 - 3 - PTE_SHIFT*/
>>> +#define PPC44x_RPN_M2		19 /*31 - PAGE_SHIFT*/
>>>     
>>
>> Uh.. you have the formulae for these things right there in the
>> comments, so why aren't you using those and avoiding this nasty
>> multiway ifdef...
>
> We need to get PMD_SHIFT and friends out of #ifndef __ASSEMBLY__ for  
> that. And some of them are under include/asm-generic so patch becomes  
> not powerpc-specific...

So use arch/powerpc/kernel/asm-offsets.c, that's what it's for.

-- 
David Gibson			| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au	| minimalist, thank you.  NOT _the_ _other_
				| _way_ _around_!
http://www.ozlabs.org/~dgibson

  reply	other threads:[~2008-09-29  2:58 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-09-10 21:53 [RFC PATCH] Support for big page sizes on 44x Ilya Yanok
2008-09-10 21:53 ` [PATCH] powerpc: add support for PAGE_SIZEs greater than 4KB for Ilya Yanok
2008-09-11 16:57   ` prodyut hazarika
2008-09-11 18:15     ` Re[2]: " Yuri Tikhonov
2008-09-11 20:09       ` Josh Boyer
2008-09-11 23:38         ` Ilya Yanok
2008-09-12  0:47           ` Josh Boyer
2008-09-11 18:28     ` Ilya Yanok
2008-09-11 18:38       ` prodyut hazarika
2008-09-11 22:44         ` Ilya Yanok
2008-09-11 23:52           ` Re[2]: " Yuri Tikhonov
2008-09-11 18:53       ` prodyut hazarika
2008-09-11 21:51         ` Ilya Yanok
2008-09-13 17:49     ` Benjamin Herrenschmidt
2008-09-13 23:37       ` Josh Boyer
2008-09-11 22:37   ` prodyut hazarika
2008-09-11 23:20     ` Re[2]: " Yuri Tikhonov
2008-09-12  3:48   ` David Gibson
2008-09-13 17:46     ` Benjamin Herrenschmidt
2008-09-26 23:43       ` Ilya Yanok
2008-09-26 23:35     ` Ilya Yanok
2008-09-29  2:58       ` David Gibson [this message]
2008-09-10 21:53 ` [PATCH] mm: fix ENTRIES_PER_PAGEPAGE overflow with 256KB pages Ilya Yanok
2008-09-12  3:50   ` David Gibson
2008-09-12  5:29     ` prodyut hazarika

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=20080929025813.GA8694@yookeroo.seuss \
    --to=david@gibson.dropbear.id.au \
    --cc=dzu@denx.de \
    --cc=linuxppc-dev@ozlabs.org \
    --cc=wd@denx.de \
    --cc=yanok@emcraft.com \
    /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).