Messages in this thread | | | From | Daniel Phillips <> | Subject | Re: Bug: Discontigmem virt_to_page() [Alpha,ARM,Mips64?] | Date | Mon, 6 May 2002 19:40:54 +0200 |
| |
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/
| |