From: Ilya Yanok <yanok@emcraft•com>
To: Milton Miller <miltonm@bga•com>
Cc: linux-ppc <linuxppc-dev@ozlabs•org>,
Vladimir Panfilov <pvr@emcraft•com>, Wolfgang Denk <wd@denx•de>,
dzu@denx•de
Subject: Re: [2/2] powerpc: support for 256K pages on PPC 44x
Date: Mon, 10 Nov 2008 19:24:08 +0300 [thread overview]
Message-ID: <49186028.8010505@emcraft.com> (raw)
In-Reply-To: <d02415a31b89736f070f290be89013d4@bga.com>
Hello Milton,
Milton Miller wrote:
>> This patch adds support for 256K pages on PPC 44x along with
>> some hacks needed for this.
>
> This description is insufficient, it describes neither the hacks nor
> why they are required.
Ok. Actually there is only one hack -- increasing kernel stack size. We
do this because with 256K pages we get division by zero in kernel/fork.c:
/*
* The default maximum number of threads is set to a safe
* value: the thread structures can take up at most half
* of memory.
*/
max_threads = mempages / (8 * THREAD_SIZE / PAGE_SIZE);
so setting THREAD_SIZE to bigger value we can avoid this. I don't think
it's very clean solution but at least we stay powerpc-specific.
>> diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
>> index 9627cfd..7df5528 100644
>> --- a/arch/powerpc/Kconfig
>> +++ b/arch/powerpc/Kconfig
>> @@ -425,6 +425,14 @@ config PPC_64K_PAGES
>> bool "64k page size" if 44x || PPC64
>> select PPC_HAS_HASH_64K if PPC64
>>
>> +config PPC_256K_PAGES
>> + bool "256k page size" if 44x
>> + depends on BROKEN
>
> I know it was not your original choice, but I feel BROKEN is too
> strong. It should be under embedded, and maybe a second choice "I am
> using standard binutils" that defaults to yes and is set to no (so
> that all yes config does not enable it by accident), but I feel
> labeling this BROKEN for an external dependency is wrong.
Hm... maybe you are right. I'm looking forward for additional comments
on this.
>> + help
>> + ELF standard supports only page sizes up to 64K so you need
>> a patched
>> + binutils in order to use 256K pages. Chose it only if you
>> know what
>> + you are doing.
>> +
>> endchoice
>>
>> config FORCE_MAX_ZONEORDER
>> diff --git a/arch/powerpc/include/asm/highmem.h
>> b/arch/powerpc/include/asm/highmem.h
>> index dc1132c..0b4ac6a 100644
>> --- a/arch/powerpc/include/asm/highmem.h
>> +++ b/arch/powerpc/include/asm/highmem.h
>> @@ -38,7 +38,8 @@ extern pte_t *pkmap_page_table;
>> * easily, subsequent pte tables have to be allocated in one physical
>> * chunk of RAM.
>> */
>> -#if defined(CONFIG_PPC_64K_PAGES) && !defined(CONFIG_PPC64)
>> +#if defined(CONFIG_PPC_256K_PAGES) || \
>> + (defined(CONFIG_PPC_64K_PAGES) && !defined(CONFIG_PPC64))
>
> Just because 256K pages is not selectable on PPC64 doesn't mean that
> this is the right grouping. However, as I said on the previous
> patch, this file is never included on PPC64 so the clause should be
> removed.
Ok.
>> diff --git a/arch/powerpc/include/asm/page_32.h
>> b/arch/powerpc/include/asm/page_32.h
>> index ebfae53..273369a 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_PPC_256K_PAGES
>> +#define PTE_SHIFT (PAGE_SHIFT - 7)
>
> This seems to be missing the comment on how many ptes are actually in
> the page that are in the other if and else cases.
Ok. I'll fix this. Actually it's another hack: we don't use full page
for PTE table because we need to reserve something for PGD
>> +#else
>> #define PTE_SHIFT (PAGE_SHIFT - 3) /* 512 ptes per page */
>> +#endif
>> #else
>> typedef unsigned long pte_basic_t;
>> #define PTE_SHIFT (PAGE_SHIFT - 2) /* 1024 ptes per page */
>> diff --git a/arch/powerpc/include/asm/thread_info.h
>> b/arch/powerpc/include/asm/thread_info.h
>> index 9665a26..3c8bbab 100644
>> --- a/arch/powerpc/include/asm/thread_info.h
>> +++ b/arch/powerpc/include/asm/thread_info.h
>> @@ -15,8 +15,12 @@
>> #ifdef CONFIG_PPC64
>> #define THREAD_SHIFT 14
>> #else
>> +#ifdef CONFIG_PPC_256K_PAGES
>> +#define THREAD_SHIFT 15
>> +#else
>> #define THREAD_SHIFT 13
>> #endif
>> +#endif
>>
>> #define THREAD_SIZE (1 << THREAD_SHIFT)
>
>
> So this appears to be the one hack. For some unknown reason, you are
> increasing the kernel stack from 8k to 32k when selecting 256k
> pages. What data structure is ballooning in size so much that you
> need the additional kernel stack space on 256k pages but not on 64k
> pages? Is this really tied to 256k base page size?
We don't really need additional stack space. Just trying to avoid
division by zero.
Regards, Ilya.
next prev parent reply other threads:[~2008-11-10 16:24 UTC|newest]
Thread overview: 35+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-10-16 2:22 [RFC PATCH] Support for big page sizes on 44x (Updated) Ilya Yanok
2008-10-16 2:22 ` [PATCH 1/2] powerpc: add 16K/64K pages support for the 44x PPC32 architectures Ilya Yanok
2008-10-17 15:54 ` prodyut hazarika
2008-10-18 12:58 ` Josh Boyer
2008-10-18 20:36 ` prodyut hazarika
2008-10-22 14:28 ` Christian Ehrhardt
2008-10-22 17:54 ` Christian Ehrhardt
2008-10-31 23:23 ` Hollis Blanchard
2008-11-01 11:30 ` Josh Boyer
2008-11-01 21:55 ` Benjamin Herrenschmidt
2008-11-02 13:41 ` Josh Boyer
2008-11-02 21:33 ` Benjamin Herrenschmidt
2008-11-03 0:33 ` Josh Boyer
2008-11-03 0:43 ` Benjamin Herrenschmidt
2008-11-03 11:26 ` Josh Boyer
2008-11-03 20:17 ` Benjamin Herrenschmidt
2008-11-03 19:55 ` Hollis Blanchard
2008-11-03 20:00 ` Josh Boyer
2008-11-05 17:33 ` Hollis Blanchard
2008-11-06 1:48 ` David Gibson
2008-11-11 13:19 ` Josh Boyer
2008-11-11 15:00 ` Hollis Blanchard
2008-11-10 15:09 ` [1/2] " Milton Miller
2008-11-10 16:50 ` Ilya Yanok
2008-10-16 2:22 ` [PATCH 2/2] powerpc: support for 256K pages on PPC 44x Ilya Yanok
2008-11-10 15:09 ` [2/2] " Milton Miller
2008-11-10 16:24 ` Ilya Yanok [this message]
2008-11-11 14:59 ` Milton Miller
2008-11-14 4:32 ` Re[2]: " Yuri Tikhonov
2008-11-14 15:41 ` Milton Miller
2008-11-27 0:30 ` Re[4]: " Yuri Tikhonov
2008-11-11 2:17 ` [RFC PATCH] Support for big page sizes on 44x (Updated) Benjamin Herrenschmidt
2008-11-11 2:22 ` Benjamin Herrenschmidt
2008-11-24 20:32 ` Hollis Blanchard
2008-11-24 23:06 ` Wolfgang Denk
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=49186028.8010505@emcraft.com \
--to=yanok@emcraft$(echo .)com \
--cc=dzu@denx$(echo .)de \
--cc=linuxppc-dev@ozlabs$(echo .)org \
--cc=miltonm@bga$(echo .)com \
--cc=pvr@emcraft$(echo .)com \
--cc=wd@denx$(echo .)de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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