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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Tue May 07 2002 - 22:00:27 EST