From: Benjamin Herrenschmidt <benh@kernel•crashing.org>
To: Ilya Yanok <yanok@emcraft•com>
Cc: linuxppc-dev@ozlabs•org, pvr@emcraft•com, dzu@denx•de, wd@denx•de
Subject: Re: [RFC PATCH] Support for big page sizes on 44x (Updated)
Date: Tue, 11 Nov 2008 13:17:48 +1100 [thread overview]
Message-ID: <1226369868.7530.60.camel@pasglop> (raw)
In-Reply-To: <1224123753-20907-1-git-send-email-yanok@emcraft.com>
On Thu, 2008-10-16 at 06:22 +0400, Ilya Yanok wrote:
> These patches add support for selecting page size on PPC 44x.
> First one adds support for 16K/64K pages while second one adds support
> for 256K pages along with some hacks.
>
> However there are still number of problems:
> 1. We can't use default PKMAP_BASE definition with 64KB/256KB pages so
> we change it. Not sure that it's optimal. Then redefined PKMAP_BASE is
> not aligned on (1<<PMD_SHIFT), don't know if it is really bad.
Well, the main thing is the implementation of kmap and kmap_atomic.
They both basically assumes that all the reserved PTEs for kmap and
kmap_atomic are in a single PTE page since it uses a simple addition
(substraction for _atomic really but heh, that's about the same).
Note that PKMAP (kmap) and FIXMAP (kmap_atomic) can be in two different
PTE pages. But it's important that the whole PKMAP is entirely contained
within a PTE page. It doesn't have to -start- on a PTE page boundary
though.
> 2. with 16KB/64KB/256KB pages WARN_ON(!pmd_none(*pmd)) is triggered
> inside dma_alloc_init() function. Not sure if it is really bad.
I think that's a bogus WARN_ON.
> 3. with 256KB pages ENTRIES_PER_PAGEPAGE in mm/shem.c become zero.
Yeah well, I'd like to keep that 256K page separate for now, let's focus
on merging 16K/64K support first.
> 4. We use asm-offsets mechanism to make PTE_SHIFT/PMD_SHIFT available in
> assembler but we don't really need the power of asm-offsets here. Maybe
> it will be more convinient to just take these defines out of #ifndef
> __ASSEMBLY__? But this would change asm-generic...
We sure should do that. I don't think of a reason why those need to
be protected by __ASSEMBLY__.
Cheers,
Ben.
next prev parent reply other threads:[~2008-11-11 2:18 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
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 ` Benjamin Herrenschmidt [this message]
2008-11-11 2:22 ` [RFC PATCH] Support for big page sizes on 44x (Updated) 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=1226369868.7530.60.camel@pasglop \
--to=benh@kernel$(echo .)crashing.org \
--cc=dzu@denx$(echo .)de \
--cc=linuxppc-dev@ozlabs$(echo .)org \
--cc=pvr@emcraft$(echo .)com \
--cc=wd@denx$(echo .)de \
--cc=yanok@emcraft$(echo .)com \
/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