linux-mips
[Top] [All Lists]

Re: [PATCH 0/2] FLATMEM: allow memory to start at pfn != 0 [take #2]

To: Franck Bui-Huu <vagabon.xyz@gmail.com>
Subject: Re: [PATCH 0/2] FLATMEM: allow memory to start at pfn != 0 [take #2]
From: peter fuerst <post@pfrst.de>
Date: Mon, 12 Mar 2007 14:03:57 +0100 (CET)
Cc: linux-mips@linux-mips.org
In-reply-to: <cda58cb80703120247q435b6bb1p8a025d8597aca2a2@mail.gmail.com>
Original-recipient: rfc822;linux-mips@linux-mips.org
References: <116841864595-git-send-email-fbuihuu@gmail.com> <Pine.LNX.4.58.0703101034500.19007@Indigo2.Peter> <cda58cb80703120247q435b6bb1p8a025d8597aca2a2@mail.gmail.com>
Reply-to: post@pfrst.de
Sender: linux-mips-bounce@linux-mips.org
Hi!

On Mon, 12 Mar 2007, Franck Bui-Huu wrote:

> Date: Mon, 12 Mar 2007 10:47:01 +0100
> From: Franck Bui-Huu <vagabon.xyz@gmail.com>
> To: post@pfrst.de
> Cc: linux-mips@linux-mips.org
> Subject: Re: [PATCH 0/2] FLATMEM: allow memory to start at pfn != 0 [take
>     #2]
>
> Hi,
>
> On 3/10/07, peter fuerst <post@pfrst.de> wrote:
> > 3) The page_offset adjustment may force fixes in other, not yet blown up,
> >    places (pmd_phys() cried out lately...).
> >
>
> Not really fair. It crashed lately because until now I was the only

May be, so i apologize.

> one to use it. And unfortunately I failed to give back this change to
> Ralf's tree.

You see the problem. Any occurrence of PAGE_OFFSET must be checked.

>
> BUT, note that the root cause of this bug is that we did _plain_
> address translation instead of using dedicated macro.
>
> So I would say that this patch helps to fix these buggy places.

Sure, a dedicated macro or function is the correct way to handle all
the kernel-addresses.  Moreover it would be desirable, if this macro
really could be used throughout the kernel, e.g. by drivers, handling
any reasonable kernel-address, which isn't possible in the page_offset
scheme anyway.

>
> > What can PHYS_OFFSET achieve here - besides obfuscating ?
> > Are there future uses for it, that justify the contortions ?
> >
>
> How do you deal with fancy cases such as physical memory starting at
> 0x20000000 for example ?

With XKPHYS and exactly this offset ;-)
To be serious again:
O.K. i see the future use is to support TLB-mapped 32bit kernels.

In this case, with respect to unmapped kernels, the min_low_pfn stuff
should be decoupled from the PHYS_OFFSET setting, to let the unmapped
kernels keep it zero and benefit from memory savings though.
Otherwise, for each different non-zero PHYS_OFFSET, there must be an
accordingly adjusted PAGE_OFFSET (the CKSEG0 part in __pa_page_offset
is still to be prepared for this).

>
> --
>                Franck
>
>

kind regards

peter



<Prev in Thread] Current Thread [Next in Thread>