Re: sparsemem support for mips with highmem

[Michael Sundius <msundius@cisco.com>]

Christoph Lameter wrote:
>
> Dave Hansen wrote:
> > On Mon, 2008-08-18 at 16:24 -0500, Christoph Lameter wrote:
> >> This overhead can be avoided by configuring sparsemem to use a 
> virtual vmemmap
> >> (CONFIG_SPARSEMEM_VMEMMAP). In that case it can be used for non 
> NUMA since the
> >> overhead is less than even FLATMEM.
> >
> > Is that all it takes these days, or do you need some other arch-specific
> > code to help out?
>
> Some information is in mm/sparse-vmemmap.c. Simplest configuration is 
> to use
> vmalloc for the populate function. Otherwise the arch can do what it 
> wants to
> reduce the overhead of virtual mappings (in the x86 case we use a 2M TLB
> entry, and since 2M TLBs are also used for the 1-1 physical mapping the
> overhead is the same as for 1-1 mappings).
>
>
Well, I finally gotten around to turning the vmemmap on for our 
sparsemem on Mips.

I have a question about what you said above and how that applies to mips.

you said that the simplest configuration is to use vmalloc for the 
populate function.
could you expand on that? (i didn't see that the populate function used 
vmalloc or maybe
we are talking about a different populate function).

I've noticed that from looking at the kernel, only 64 bit processors or 
at least processors
that use a 3 level page table have the vmemmap_populate() function 
implemented.

in looking at the function vmemmap_populate_basepages() (called by most 
vmemmap_populate funcs)
it seems to create a 3 level
page table. not sure what my question here is, but maybe what do I have 
to do to make
this work w/ mips which i understand uses only 2 levels can I just take 
out the part of
the function that sets up the middle level table?

Has anyone done this on mips?

mike





     - - - - -                              Cisco                            - - - - -         
This e-mail and any attachments may contain information which is confidential, 
proprietary, privileged or otherwise protected by law. The information is solely 
intended for the named addressee (or a person responsible for delivering it to 
the addressee). If you are not the intended recipient of this message, you are 
not authorized to read, print, retain, copy or disseminate this message or any 
part of it. If you have received this e-mail in error, please notify the sender 
immediately by return e-mail and delete it from your computer.

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>