Re: Bug: Discontigmem virt_to_page() [Alpha,ARM,Mips64?]

[Daniel Phillips]

This thread is already long enough, I propose that after your response
to this we take it private.  The executive summary of this post is:
"show me the code".

On Monday 06 May 2002 04:06, Andrea Arcangeli wrote:

> You can implement __va as you want, it doesn't need ot be a simple
> linear relation (see also the attached email from Roman),

Here's the relevant comment from Roman:

> I mean to map the memory where you need it. The physical<->virtual
> mapping won't be one to one, but you won't need another abstraction and
> the current vm is already basically able to handle it.
> 
> bye, Roman

Roman is talking about an implementation idea that so far hasn't been
presented in the form of working code.  I have already imlemented __va
as I want, it works, it's efficient, it's simple, clean, powerful and
extensible.  If Roman has an alternative, I'd be interested in looking
at the patch.

> but regardless
> what matters really is page_address and virt_to_page, not only __va,
> just initialize page->virtual to the static kernel window at boot time

OK, so you want to tie things to page->address.  It's an interesting
proposition, I'd like to see your code.

Keep in mind that your new use of page->address conflicts with the
current move to get rid of it from mainline, except for highmem use.
I also have doubts about the efficiency and cleanliness your proposal.
Your __pa and __va are going to get more expensive because they now
have to work through the struct page, requiring multiplies as well
as lookups.  I think you'll end up with something more complex and
less efficient than config_nonlinear - please prove me wrong by
showing me the code.

You also need some sort of structure that tells you how to set up your
static mapping in the kernel.  I already have that, you still need to
describe it.  In fact, config_nonlinear's way of doing the mem_map
initialization required no changes at all to the mem_map initialization
code.  Such results tend to suggest a particular design approach is
indeed correct.

Now, it would be interesting to see exactly what changes are required
to config_nonlinear to allow it to cover numa usage as well as
non-numa usage.  As far as I can see, I simply have to elaborate the
my mapping between pagenum and struct page, i.e., I have to do what's
necessary to put the mem_map structure into the local node.  I
believe that's possible without requiring any double table lookups.

Note that for NUMA-Q, the ->lmem_map arrays are currently off-node for
all but node zero, so the per-node ->lmem_map is doing nothing for
NUMA-Q at the moment.  In order for this to make sense for NUMA-Q, I
really do have to provide a local mapping of a portion of zone_numa,
otherwise we might as well just use config_nonlinear in its current
form.

-- 
Daniel