All of lore.kernel.org
 help / color / mirror / Atom feed
From: Yuri Tikhonov <yur@emcraft.com>
To: Milton Miller <miltonm@bga.com>
Cc: linux-ppc <linuxppc-dev@ozlabs.org>,
	dzu@denx.de, Vladimir Panfilov <pvr@emcraft.com>,
	Ilya Yanok <yanok@emcraft.com>, Wolfgang Denk <wd@denx.de>
Subject: Re[2]: [2/2] powerpc: support for 256K pages on PPC 44x
Date: Fri, 14 Nov 2008 07:32:49 +0300	[thread overview]
Message-ID: <828133638.20081114073249@emcraft.com> (raw)
In-Reply-To: <f6812adbe26a68b0545f5fd25b6d9d6a@bga.com>

Hello Milton,

On Tuesday, November 11, 2008 Milton Miller wrote:

[snip]

>>>>
>>>>  #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

> I don't understand "we need to reserve something for PGD".   Do you=20
> mean that you would not require a second page for the PGD because the=20
> full pagetable could fit in one page?   My first reaction was to say=20
> then create pgtable-nopgd.h like the other two.  The page walkers=20
> support this with the advent of gigantic pages.  Then I realized that=20
> might not be optimal:  while the page table might fit in one page, it=20
> would mean you always allocate the pte space to cover the full address
> space.   Even if your processes spread out over the 3G of address space
> allocated to them (32 bit kernel), you will allocate space for 4G,=20
> wasting 1/4 of the pte space.
> That does imply you want to allocate the pte page from a slab instead=20
> of pgalloc.  Is that covered?

 Well, in case of 256K PAGE_SIZE we do not need the PGD level indeed
(18 bits are used for offset, and remaining 14 bits are for PTE index=20
inside the PTE table). Even the full 256K PTE page isn't necessary to=20
cover the full range: only half of it would be enough (with 14 bits we=20
can address only 16K PTEs).

 But the head_44x.S code is essentially based on the assumption of=20
2-level page addressing. Also, I may guess that eliminating of the
PGD level won't be as easy as just a re-implementation of the TLB-miss=20
handlers in head_44x.S. So, the current approach for 256K-pages=20
support was just a compromise between the required for the project=20
functionality, and the effort necessary to achieve it.

 Regards, Yuri

 --
 Yuri Tikhonov, Senior Software Engineer
 Emcraft Systems, www.emcraft.com

  reply	other threads:[~2008-11-14  4:33 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         ` Yuri Tikhonov [this message]
2008-11-14 15:41           ` Re[2]: " 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=828133638.20081114073249@emcraft.com \
    --to=yur@emcraft.com \
    --cc=dzu@denx.de \
    --cc=linuxppc-dev@ozlabs.org \
    --cc=miltonm@bga.com \
    --cc=pvr@emcraft.com \
    --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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.