[Top] [All Lists]

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

To: Franck Bui-Huu <>
Subject: Re: [PATCH 0/2] FLATMEM: allow memory to start at pfn != 0 [take #2]
From: peter fuerst <>
Date: Mon, 12 Mar 2007 14:03:57 +0100 (CET)
In-reply-to: <>
Original-recipient: rfc822;
References: <> <Pine.LNX.4.58.0703101034500.19007@Indigo2.Peter> <>

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

> Date: Mon, 12 Mar 2007 10:47:01 +0100
> From: Franck Bui-Huu <>
> To:
> Cc:
> Subject: Re: [PATCH 0/2] FLATMEM: allow memory to start at pfn != 0 [take
>     #2]
> Hi,
> On 3/10/07, peter fuerst <> 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


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